Представьте, что вы требуете, чтобы у вас было 3 огромные таблицы (структурированные данные), скажем, по 30 миллиардов строк в каждой (общий размер 4 ТБ), и многим вашим одновременным пользователям (которые являются параллельными потоками os на машинах с удаленной локальной сетью) потребуется прочитать часть данные с помощью запросов SELELCT WHERE GROUPBY и высокой одновременности, скажем, 10 000 одновременных чтений одновременно, а также пользователи должны вставлять (не обновлять) данные в эти таблицы с высокой степенью одновременности, например 2000 одновременных писателей (по всей локальной сети центра обработки данных) , Пользователи хотели бы читать и вставлять как можно быстрее из этого хранилища, где каждое чтение и запись будет происходить в диапазоне от мс до 1 секунды.
Какие технологии вы рекомендуете для удовлетворения такого требования? Есть ли какое-либо хранилище данных или хранилище значений ключей, которые могли бы сделать это? Облако не вариант.
Некоторые разъяснения:
Пользователи НЕ должны видеть данные сразу, и возможная последовательность приемлема. Доступ к данным осуществляется через любой драйвер, который может предоставить хранилище, и пользователи снова становятся потоками, работающими на удаленных компьютерах центра обработки данных. Запросы в основном похожи на SELECT WHERE GROUPBY.
Данные представлены в табличном формате, и каждая строка занимает около 60 байтов.
Нет облачного варианта, где я не могу использовать DynamoDB или аналогичные решения. Я должен иметь возможность разместить его внутри в центре обработки данных.
Все данные таблиц могут быть прочитаны все время, а модель использования непредсказуема. Нет соединения или супер длинный запрос. DR не требуется, но необходим разумный HA, но он не должен быть модным. Каждый читатель получает пакеты строк, основанные на выражении where и строках, которые на самом деле не связаны. Возможно, мы можем иметь фиксированную длину для каждой строки, но я надеюсь, что уровень хранилища будет беспокоиться об этом.
Кроме того, моя самая большая проблема - все те одновременные записи, которые происходят с одновременными чтениями.
Ваше понимание этого высоко ценится.
И еще, у меня есть три из этих таблиц с каждыми 30 миллиардами строк, содержащих разные типы объектов
Ответы:
Если возможная согласованность приемлема и все ваши запросы являются агрегатными, то, возможно, система OLAP с низкой задержкой может работать для вас. Ваше требование звучит как алгоритмическая торговая платформа. Этот тип архитектуры часто используется в системах торговых площадок, где требуется выполнять статистические расчеты агрегированного статистического анализа актуальных данных.
Если вы можете разбить данные по дате, а старые строки не будут обновлены, вы можете создать гибридную систему OLAP, используя обычный сервер OLAP, такой как службы Microsoft Analysis, поддерживаемые обычной платформой RDBMS. Должна быть возможность справиться с ~ 4 ТБ данных, и SQL Server и SSAS будут создавать кластеры с общим диском. Подобные системы OLAP (например, Oracle / Hyperion Essbase) доступны от других поставщиков.
Серверы OLAP работают, сохраняя данные в собственном хранилище вместе с агрегатами. Большинство будет поддерживать секционированные данные. Кроме того, большинство из них также будет работать в режиме ROLAP, где они выдают запросы к базовой базе данных. Важно отметить, что стратегией хранения можно управлять для каждого раздела, и вы можете переключать разделы с одного на другой программно,
В этой модели исторические данные хранятся в разделах MOLAP с сохранением совокупности данных. Если запрос может быть выполнен из агрегатов, то сервер будет использовать их. Агрегаты могут быть настроены в соответствии с запросами, и правильные агрегаты значительно уменьшат объем вычислений, необходимых для разрешения запроса. С этим типом системы возможны очень отзывчивые совокупные запросы.
Данные в реальном времени можно реализовать, поддерживая небольшой ведущий раздел - за текущий месяц, день или даже час, если необходимо. Сервер OLAP будет выдавать запросы к базе данных; если этот раздел достаточно мал, СУБД сможет быстро ответить. Обычный процесс создает новые ведущие разделы и преобразует закрытые исторические периоды в MOLAP. Старые разделы могут быть объединены, что позволяет управлять историческими данными с любой требуемой зернистостью.
Клиенты, пишущие в базу данных, просто пишут прямо в основную СУБД. Если исторические данные остаются статичными, они будут записывать только в ведущий раздел. 4TB - это практичный том для использования SSD, если вам нужна дополнительная производительность СУБД. Даже основные поставщики имеют в качестве опции предложения на основе SSD с более быстрыми модулями SLC.
источник