Какой хороший выбор для обработки данных в реальном времени в памяти?

Question

Клиенты отправляют данные в режиме реального времени на сервер. Сервер выполнит простой анализ с этими данными. Он только находит данные из определенного диапазона или сортирует некоторые данные. Большая часть данных будет оставлена ​​после анализа, поэтому нет необходимости сохранять их на диске.

Я хочу использовать БД памяти для работы с ними. Является ли механизм памяти MYSQL хорошим выбором? Как насчет того, чтобы использовать какой-нибудь механизм кэширования памяти значения ключа, такой как Redis? Поскольку мне нужно сравнить данные, возможно, хранилище чистых ключей не может удовлетворить мои требования.

Answer 1

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

Redis поддерживает расширенные структуры данных, что делает его довольно удобным хранилищем данных на основе значений ключей, однако если ваши данные требуют сложных отношений, вам, вероятно, следует проверить MongoDB , OrientDB или Riak , который должен поддерживать механизмы хранения на основе памяти.

Answer 2

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

Если структура проста, а операции просты, то вам, вероятно, следует хранить данные в структурах данных используемой вами платформы программирования.

Answer 3

Если вы планируете использовать механизм памяти MySQL, есть несколько ошибок:

• по умолчанию индексы реализованы с использованием хеш-таблиц, а не btrees. Если вам нужно отсортировать данные или поддержать диапазон, использование btrees может быть более интересным.

• Детализация блокировки таблицы. Существует блокировка R / W для защиты от одновременных операций DML. Хотя чистая производительность не плохая, масштабируемость не очень хорошая, когда у вас много писателей одновременно.

• все строки имеют фиксированную ширину (будьте осторожны, если вам нужно хранить varchars ...)

Кроме того, как и большинство других СУБД, протокол MySQL является синхронным. Каждый раз, когда клиенты будут писать в базу данных, они будут ждать ответа. Если у вас много данных, операции пакетной записи почти обязательны для достижения хорошей производительности.

Это действительно зависит от объема, количества клиентов и пропускной способности. Если требования низкие, то любое решение для хранения (включая MySQL) будет работать нормально. Теперь, если потребуется больше производительности или больше масштабируемости, другие решения, вероятно, будут лучше.

То, что вы хотите написать, - это, вероятно, приложение DIRT (интенсивное использование данных в реальном времени). Хорошими решениями для хранения данных являются MongoDB (поддержка upserts, односторонний протокол для операций записи и т. Д.) И Redis (операции в памяти, O (1), конвейеризация и т. Д.). В зависимости от ваших потребностей моделирование и обработка данных, возможно, будет проще с MongoDB благодаря индексам btree и поддержке карты / сокращения. Возможно, с Redis все будет немного сложнее, но если вы выберете правильную структуру данных, вы получите более детерминированную производительность.

Наконец, вы также можете избежать хранения данных, обрабатывая их на лету. Вы можете достичь этого с помощью потокового движка, такого как те, что используются на высокоскоростных торговых платформах. Например, если вы готовы писать код на Java, ESPER является отличным CEP-решением для обработки потоков данных и / или установления корреляции между потоками с использованием языка, подобного SQL.