Большой (> 22 триллиона элементов) набор геопространственных данных с быстрой (<1 с) производительностью запросов чтения

Я нахожусь в процессе разработки новой системы для большого набора геопространственных данных, которая потребует быстрой обработки запросов на чтение. Поэтому я хочу посмотреть, думает ли кто-нибудь, что это возможно, или имеет опыт / совет относительно подходящих СУБД, структуры данных или альтернативных методов для достижения требуемой производительности в следующей ситуации:

Данные будут непрерывно получаться из обработанных спутниковых радиолокационных данных, которые будут иметь глобальный охват. Исходя из спутникового разрешения и охвата земного шара, я оцениваю полный набор данных для получения значений в 75 миллиардах дискретных точек земного шара. В течение срока службы одного спутника выходной сигнал будет давать до 300 значений в каждом из этих местоположений (таким образом, общий набор данных> 22 триллионов значений). Это для одного спутника, а на орбите уже есть второй, а еще два планируется в ближайшие несколько лет. Так что данных будет много! Один элемент данных очень прост и будет состоять только из (долготы, широты, значения), но из-за количества элементов, по моим оценкам, один спутник может произвести до 100 ТБ.

Записанные данные никогда не должны обновляться, поскольку они будут только расти по мере обработки новых спутниковых приобретений. Производительность записи не важна, но производительность чтения имеет решающее значение. Цель этого проекта - иметь возможность визуализировать данные через простой интерфейс, такой как слой поверх карт Google, где каждая точка имеет цветное значение, основанное на ее среднем значении, градиенте или некоторой функции во времени. (демо в конце поста).

Исходя из этих требований, база данных должна быть масштабируемой, и мы, вероятно, обратимся к облачным решениям. Система должна иметь возможность обрабатывать геопространственные запросы, такие как «точки рядом (широта, долгота)» и «точки внутри (прямоугольник)», и иметь скорость чтения <1 с для определения местоположения одной точки, а также полигоны, которые содержат до 50000 баллов (хотя до 200 000 баллов будет предпочтительнее).

На данный момент у меня есть набор тестовых данных из ~ 750 миллионов элементов данных в 111 миллионах точек. Я опробовал экземпляр postgres / postGIS, который работал нормально, но без возможности разделения я не смогу справиться с этим по мере роста данных. Я также опробовал экземпляр mongoDB, который снова кажется OK, так что далеко, и с шардингом может быть достаточно масштабировать с объемом данных. Недавно я немного узнал об упругом поиске, поэтому любые комментарии по этому поводу были бы полезны, так как это ново для меня.

Вот быстрая анимация того, чего мы хотим достичь с полным набором данных:

Этот gif (из моего теста postgres) обслуживает (6x3) предварительно вычисленные растровые тайлы, каждый из которых содержит ~ 200 000 точек и ~ 17 с, чтобы сгенерировать каждый. При щелчке по точке график составляется путем извлечения всех исторических значений в ближайшем месте за <1 с.

Извиняюсь за длинный пост, все комментарии / советы приветствуются.

Вы можете осколок по месту. Разделите глобус на сетку и поместите каждый квадрат этой сетки на один сервер. Поскольку вы упомянули облако, это было бы хорошо для облака. Конечно, вам нужно будет вручную объединить результаты с нескольких серверов.

Таким образом, вы можете использовать любое решение для базы данных, которое вам нравится. Он не должен быть масштабируемым сам по себе.

Отдельные квадраты будут иметь разные объемы данных. Вы можете использовать для них машины разного размера (поскольку это облако) или поместить несколько маленьких осколков на одну машину.

Эта схема шардинга отлично подходит для тех запросов, которые вы выполняете, потому что каждый запрос должен касаться только нескольких сегментов. Разделение по времени хуже, потому что все фрагменты времени должны быть затронуты для каждого запроса. Случайный шардинг имеет ту же проблему.

В общем, это случай легкого разделения, поскольку шаблон запроса так хорошо соответствует схеме разделения.

На самом деле, мне интересно, нужна ли вообще база данных для этого. Может быть, вы можете разделить земной шар на 1000x1000 плиток или меньше и иметь один плоский файл в хранилище больших двоичных объектов для каждой плитки. Хранилище BLOB-объектов вообще не против 1M-объектов.

С этой схемой хранения концептуально очень просто выполнить запрос. Вы можете также хранить данные в нескольких разрешениях сетки.

Насколько актуальными должны быть ваши запросы на чтение?

Вы можете разбить базу данных по времени, если на карте просто нужно показать самые последние измерения. Это уменьшит нагрузку на ваш запрос для карты.

Для истории данной точки, вы можете держать второй магазин по x и y, показывая историю. Это можно сделать с ночным обновлением / обновлением, поскольку исторические данные не изменятся.

Затем вы можете предварительно рассчитать средние значения при более грубых разрешениях для интеграции с картами с различными уровнями масштабирования. Это уменьшит количество точек, которые нужно получить для больших областей карты (уменьшение). Более точные разрешения будут использоваться для большего увеличения на картах, которые запрашивают меньшие области. Если вам действительно нужно ускорить это, вы можете вычислять плитки как капли и интерпретировать их в своем приложении.

Поскольку это потребует некоторого повторного вычисления совокупной информации, в результатах запроса будет некоторая задержка. В зависимости от того, какая задержка была приемлемой, вы можете использовать этот подход для оптимизации чтения.

Итак, ваши баллы должны быть вычислены как средние по времени. Я полагаю, что с помощью этих вычислений ваши фактические запросы значительно уменьшатся из 22 триллионов элементов, поскольку растровые значения можно предварительно рассчитать для запросов.

Похоже, что существует два класса запросов - один для понимания того, какие местоположения лежат в текущем окне просмотра, и второй для предоставления желаемой статистики для этих точек. Я предлагаю использовать отдельные, специализированные инструменты для каждого.

Я предполагаю, что все измерения относятся к одному и тому же набору 75 млрд. Баллов. Эти широты / долготы, как только они установлены, поэтому являются статическими. Они могут быть сгруппированы, агрегированы и проиндексированы по разовым ценам. Поэтому я бы рекомендовал шардинг по регионам и уровню масштабирования. Размер каждого осколка будет зависеть от производительности, которая может быть достигнута от каждого экземпляра ГИС.

ГИС будет возвращать набор точек, которые передаются в базу данных временных рядов. Это содержит измеренные значения и выполняет агрегаты. KDB - это тот, о котором я знаю. Он нацелен на торговлю ценными бумагами, который будет иметь меньше ключей, но больше точек данных на ключ, чем ваш сценарий.

За передачу значений ключей с ГИС-сервера в БД временных рядов будет взиматься плата. Моя гипотеза состоит в том, что эта стоимость будет возмещена более быстрой обработкой в ​​БД временных рядов для конкретной задачи. Из формулировки вопроса видно, что один экземпляр не сможет содержать все данные, поэтому некоторый межсерверный трафик кажется неизбежным. Учитывая относительную скорость компонентов, кажется, что отправка набора ключей на удаленный сервер, на котором данные кэшированы, будет быстрее, чем чтение данных с локального диска.

Если части определения точек и вычисления значений могут быть локальными друг для друга, то, конечно, я ожидаю, что реакция будет быстрее. Мое (ограниченное) понимание состоит в том, что поиск N ближайших соседей к данной точке является нетривиальной задачей. Вот почему я предложил использовать специальное программное обеспечение для его выполнения. Если наведение может быть уменьшено до

where latitude between x1 and x2
and logitude between y1 and y2

затем эта часть может быть обработана программным обеспечением для хранения значений, а ГИС исключена из архитектуры.

Я не внедрил такую ​​систему. Я действительно просто думаю здесь вслух. В петабайтном масштабе нет готовых решений. Однако есть много поставщиков спутниковых данных, поэтому ваша проблема решаема. Удачи.