NoSql решение для хранения 20 [ТБ] данных, как вектор / массив?

Question

Мне нужно создать систему для эффективного хранения и обслуживания огромного количества (20 [ТБ]) данных (и возможности доступа к ним в «векторной» форме).Вот мои размеры:

(1) time (given as an integer of the form YYYYMMDDHHMMSS)

(2) field (a string of any given length, representing a name of a hospital)

(3) instrumentID (an integer representing a uniqueID for the instrument)

Мне понадобится способ хранить данные по отдельности, что-то вроде:

STORE 23789.46 as the data for instrumentID = 5 on field = 'Nhsdg' on time = 20040713113500

Тем не менее, мне понадобится следующий запрос для запуска FAST : give me all instruments for field 'X' on timestamp 'Y'.

Для построения этих систем мне дано 60 двухъядерных машин (каждая с 1 ГБ ОЗУ, диском 1,5 ТБ)

Любые рекомендации по подходящему решению NoSQL (в идеалеработа с python)?

ПРИМЕЧАНИЕ : система сначала будет хранить исторические данные (что составляет примерно 20 [ТБ]).Каждый день я добавляю не более 200 [МБ] максимум.Мне просто нужно решение, которое будет масштабироваться и масштабироваться.Мой вариант использования будет простой запрос: give me all instruments for field 'X' on timestamp 'Y'

Answer 1

MongoDB отлично масштабируется и поддерживает многие функции индексирования, которые вы обычно найдете в СУБД, такие как индексы составных ключей . Вы можете использовать составной индекс для атрибутов name и time в ваших данных. Затем вы можете получить все показания прибора с определенным именем и диапазоном дат.

[Теперь в простом случае, когда вас строго интересует только один базовый запрос и ничего больше, вы можете просто объединить имя и временную метку и назвать этот ключ, который будет работать в любом хранилище значений ключей. .]

HBase - еще один отличный вариант. Вы можете использовать составной ключ строки для имени и даты.

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