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

Question

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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