Каков наиболее эффективный способ хранения сопоставления «ключ -> поток событий»?

Question

Предположим, есть ~ 10000 ключей, где каждый ключ соответствует потоку событий. Я бы хотел поддержать следующие операции:

• push(key, timestamp, event) - отправляет событие в очередь событий для ключа, отмеченного данной отметкой времени. Гарантируется, что временные метки событий для определенного ключа помещаются в отсортированном или почти отсортированном порядке.
• tail(key, timestamp) - получить все события для ключа с заданной отметки времени. Обычно запросы меток времени для данного ключа почти монотонно увеличиваются, почти синхронно с нажатиями на тот же ключ.

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

Какая структура базы данных оптимальна для этой задачи? Было бы лучше использовать реляционную базу данных, хранилище значений ключей или что-то еще?

Answer 1

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

Если вы пойдете по этому пути, я предлагаю иметь каталог для каждого «Ключа» и организовать их в подкаталогах.

Т.е., предположим, у вас есть такой ключ: HJ029084930A

Вы должны иметь:

/streams
/streams/HJ02
/streams/HJ02/9084
/streams/HJ02/9084/930A/HJ029084930A
/streams/HJ02/9084/930A/HJ029084930A/20100315/230257.trc
/streams/HJ02/9084/930A/HJ029084930A/20100316/000201.trc
/streams/HJ02/9084/930A/HJ029084930A/20100316/000203.trc
/streams/HJ02/9084/930A/HJ029084930A/20100316/010054.trc
...
/streams/HJ02/9084/930A/HJ029084930A/20100317/010230.trc

Я намекаю на то, что вы должны сделать все возможное, чтобы избежать "слишком большого количества" файлов (или каталогов) внутри каталога, иначе ОС может замедлить получение ваших данных.

Одна из возможных проблем - когда поток перекрывается с конца дня до начала следующего. Посмотрите, можете ли вы разделить его так, чтобы он мог завершиться в 23:59:59 и создать новый, начиная с 00:00:00 следующего дня. Это зависит от того, какова семантика "tail ()" в вашем случае.

Answer 2

Работа с финансовыми данными? ;) У меня есть приложение, которое обрабатывает 1,5 миллиона таких потоков (полная подача CME) в тестах;)

Относительный - вы МОЖЕТЕ сделать это, но это бесполезно. То, что я сделал, - это двоичное хранилище PER STREAM и поместил значения в дельта-формат, который является двоичным эффективным (временные метки всегда растут - поэтому нет необходимости сохранять их суммарными, только небольшая ldelta от alst). Я храню их в настоящее время в 15-минутных срезах, и система для извлечения хвоста знает, как получить данные. Также значительно снижает нагрузку на реляционную сторону.

Для этого есть специализированные базы данных, но они непристойные (10.000 долларов США за процессорное ядро, минимальная лицензия 8 ядер - да, верно).

Некоторые приложения работают с плоскими файлами (по одному на клавишу), даже в приложениях в стиле торговли. Лично мне это не нравится.