Великий (> 22 трлн. Елементів) геопросторовий набір даних з швидкою (<1) ефективністю запиту читання

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

Дані будуть постійно вироблятися з оброблених супутникових радіолокаційних даних, які матимуть глобальне покриття. На основі роздільної здатності супутника та покриття земної кулі, я оцінюю повний набір даних для отримання значень у 75 мільярдів дискретних місць на земній кулі. Протягом тривалості життя одного супутника вихід буде виробляти до 300 значень у кожному з цих місць (тому загальний набір даних> 22 трлн. Значень). Це для одного супутника, а на орбіті вже є другий, ще два заплановані на нові кілька років. Так що буде багато даних! Один елемент даних дуже простий і складається лише з (довгота, широта, значення), але завдяки кількості елементів я оцінюю, що один супутник може виробляти до 100 ТБ.

Письмові дані ніколи не потребуватимуть оновлення, оскільки вони лише зростатимуть із обробкою нових придбань супутників. Ефективність запису не важлива, але виконання читання має вирішальне значення. Мета цього проекту - мати можливість візуалізувати дані за допомогою простого інтерфейсу, такого як шар над картами Google, де кожна точка має кольорове значення на основі свого середнього, градієнта чи певної функції з часом. (демонстрація в кінці повідомлення).

Виходячи з цих вимог, базу даних потрібно масштабувати, і ми, швидше за все, будемо дивитись на хмарні рішення. Система повинна мати можливість обробляти геопросторові запити, такі як "точки поблизу (лат., Лон)" та "точки всередині (поле)", і читати продуктивність <1s для розміщення однієї точки та полігони, які містять до 50 000 балів (хоча до 200 000 балів було б кращим).

Поки що у мене є набір тестових даних ~ 750 мільйонів елементів даних у 111 мільйонах місць. Я випробував екземпляр postgres / postGIS, який працював нормально, але без можливості різкості я цього не зможу впоратися, оскільки дані зростають. Я також випробував екземпляр mongoDB, який знову видається так далеко, і при різкому збільшенні можливо, це буде достатньо для масштабування з обсягом даних. Нещодавно я трохи дізнався про еластичний пошук, тому будь-які коментарі з цього приводу були б корисними, оскільки це для мене нове.

Ось коротка анімація того, що ми хочемо досягти за допомогою повного набору даних:

Цей gif (з мого випробування на постгресі) обслуговує (6x3) попередньо обчислені растрові плитки, кожна з яких містить ~ 200 000 балів і займає ~ 17s для їх генерування. Клацнувши по точці, графік складається, витягнувши всі історичні значення у найближчому місці через <1s.

Вибачте за довгий пост, всі коментарі / поради вітаються.

Ви можете розмістити їх за місцем розташування. Розділіть земну кулю на сітку та розмістіть кожен квадрат у цій сітці на одному сервері. Оскільки ви згадали хмару, це було б добре підходити до хмари. Звичайно, вам потрібно буде вручну об'єднати результати з декількох серверів.

Таким чином ви можете використовувати будь-яке рішення бази даних, яке вам подобається. Його не потрібно масштабувати самостійно.

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

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

Загалом, це легкий випадок загострення, тому що схема запиту так добре відповідає схемі заточування.

Власне, мені цікаво, чи взагалі вам потрібна база даних для цього. Можливо, ви можете розділити земну кулю на плитки 1000x1000 або менше і мати один плоский файл у сховищі для кожної плитки. Зберігання Blob взагалі не проти 1M краплі.

Виконання запиту в цій схемі концептуально дуже просто. Ви також можете надмірно зберігати дані у кількох дозволах сітки.

Наскільки актуальними повинні бути ваші запитання для читання?

Ви можете розділити базу даних за часом, якщо на карті просто потрібно показати останнє вимірювання. Це призведе до зменшення завантаження запиту для карти.

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

Тоді ви можете попередньо обчислити середні значення при більш грубих дозволах для інтеграції з картами на різних рівнях збільшення. Це зменшило б кількість очок, які потрібно отримати для великих областей карти (зменшити масштаб). Більш чіткі дозволи використовуються для збільшення масштабів карт, які запитують менші області. Якщо вам дійсно потрібно прискорити це, ви можете обчислити плитки як краплі і інтерпретувати їх у своїй програмі.

Оскільки це передбачало б певне перерахування сукупної інформації, було б затримка в результатах запитів. Залежно від того, яка затримка була прийнятною, ви можете використовувати такий підхід для оптимізації своїх читань.

Гаразд, тому ваші бали потрібно обчислювати в середньому за часом. Завдяки цьому обчисленню я думаю, що ваші фактичні запити зменшуються з 22 трильйонів елементів, оскільки растрові значення можна заздалегідь обчислити для запиту.

Здається, є два класи запитів - один, щоб зрозуміти, які місця знаходяться у поточному вікні перегляду, а другий, щоб доставити бажану статистику для цих точок. Моя пропозиція - використовувати окремі спеціалізовані інструменти для кожного.

Я припускаю, що всі вимірювання стосуються одного і того ж набору 75Bn балів. Ці лати / довги, колись встановлені, є статичними. Вони можуть бути згруповані, зведені та індексовані за разовою вартістю. Тому я б запропонував різкість за регіонами та рівнем збільшення. Розмір кожного фрагмента визначатиметься ефективністю, яку можна досягти від кожного GIS-примірника.

ГІС поверне набір точок, переданих у базу даних часових рядів. Це утримує виміряні значення та виконує агрегати. КДБ - це той, кого я знаю. Він націлений на торгівлю цінними паперами, в якій буде менше ключів, але більше точок даних на ключ, ніж у вашому сценарії.

Передача ключових значень з GIS-сервера до БД тимчасових витрат буде витратна. Моя гіпотеза полягає в тому, що ці кошти будуть повернені шляхом швидшої обробки в БД, що відповідає специфічним завданням. З формулювання запитання виходить, що жоден екземпляр не зможе зберігати всі дані, тому деякий трафік між серверами здається неминучим. Зважаючи на відносну швидкість компонентів, мабуть, надіслати набір клавіш віддаленому серверу, який має кешовані дані, буде швидше, ніж зчитування даних з локального диска.

Якщо частини точок пошуку та обчислення вартості можуть бути локальними один для одного, то, звичайно, я б очікував, що реакція буде швидшою. Моє (обмежене) розуміння полягає в тому, що знайти N найближчих сусідів до даної точки - це нетривіальне завдання. Ось чому я запропонував використовувати для цього певне програмне забезпечення. Якщо точку пошуку можна звести до

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

тоді ця частина може бути оброблена програмним забезпеченням, що зберігає значення, а ГІС усувається з архітектури.

Я не запровадив таку систему. Я тут справді просто голосно думаю. У петабайтній шкалі немає позаштатних рішень. Однак є багато постачальників супутникових даних, тому ваша проблема відстежується. Удачі.