Високо сумісна система зберігання

Уявіть, що ваша вимога полягає в тому, що у вас є 3 величезні таблиці (структуровані дані) з по 30 мільярдами рядків у кожній (загальний розмір 4 ТБ), і ваші багато одночасних користувачів (які є паралельними OS-потоками на віддалених комп'ютерах локальної мережі) повинні прочитати частину дані за допомогою SELELCT WHERE GROUPBY запитів і дуже одночасних, скажімо, 10 000 одночасно читає одночасно, а також користувачам потрібно вставляти (не оновлювати) дані в ці таблиці дуже одночасно, як 2000 одночасних письменників (у всій мережі локального центру даних) . Користувачі хотіли б прочитати та вставити якомога швидше з цього сховища, де буде відбуватися кожне читання та запис, що становить мс до 1 секунди.

Які технології ви рекомендуєте задовольнити такій вимозі? Чи є сховище даних або сховище ключових значень, яке могло б це зробити? Хмара НЕ є варіантом.

Деякі роз'яснення:

Користувачі НЕ повинні бачити дані відразу, і можлива узгодженість є прийнятною. Доступ до даних здійснюється через будь-який драйвер, який зберігання може надати, і користувачі знову просто потоки, що працюють на віддалених машинах центру обробки даних. Запити здебільшого схожі на ВИБІРИТЬ, де ГРУПИ.

Дані мають табличний формат, і кожен рядок - близько 60 байт.

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

Усі дані таблиць можна читати весь час, а схема використання непередбачувана. Немає запиту на приєднання чи наддовгий запит. Ніяких DR не потрібно, але розумний HA не потрібен, але він не повинен бути фантазійним. Кожен читач отримує партії рядків на основі того, де пункт та рядки насправді не пов'язані. Ми, мабуть, можемо мати фіксовану довжину для кожного ряду, але сподіваюся, що шар зберігання буде турбуватися про це.

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

Ваша думка про це високо цінується.

І ще більше: у мене є три з цих таблиць, кожні 30 мільярдів рядків містять різні типи об'єктів

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

Якщо ви можете розділити свої дані за датою, а старі рядки не оновлюються, ви можете створити гібридну систему OLAP, використовуючи звичайний сервер OLAP, наприклад сервіси Microsoft Analysis, підтримувані звичайною платформою RDBMS. Потрібно зробити так, щоб це справлялося з ~ 4 ТБ даних, і SQL Server і SSAS будуть робити кластери спільного диска. Подібні системи OLAP (наприклад, Oracle / Hyperion Essbase) доступні у інших постачальників.

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

У цій моделі історичні дані зберігаються у розділах MOLAP, де зберігаються також агрегати даних. Якщо запит можна задовольнити з агрегатів, сервер їх буде використовувати. Агрегати можуть бути налаштовані на відповідність запитам, а правильні агрегати значно зменшать кількість обчислень, необхідних для вирішення запиту. З цим типом системи можливі дуже чуйні сукупні запити.

Дані в реальному часі можна реалізувати, підтримуючи невеликий провідний розділ - за поточний місяць, день або навіть годину, якщо це необхідно. Сервер OLAP видаватиме запити до бази даних; якщо цей розділ досить малий, СУБД зможе швидко реагувати. Регулярний процес створює нові провідні розділи та перетворює закриті історичні періоди в MOLAP. Старіші розділи можна об'єднати, що дозволяє керувати історичними даними на будь-якому бажаному зерні.

Клієнти, що записують у базу даних, просто записують основні RDBMS. Якщо історичні дані залишаться статичними, вони записуватимуться лише до провідного розділу. 4 ТБ - це практичний об'єм для використання SSD, якщо вам потрібна додаткова продуктивність СУБД. Навіть основні постачальники мають опцію на основі SSD із швидшими SLC-модулями.