В наших системах существует ситуация, когда пользователь может просматривать и «закрывать» отчет. После их закрытия отчет перемещается во временную таблицу внутри базы данных, где она хранится в течение 24 часов, а затем перемещается в таблицу архивов (где отчет хранится в течение следующих 7 лет). В любой момент в течение 7 лет пользователь может «повторно открыть» отчет и работать над ним. Проблема в том, что хранение архивов становится большим, и поиск/повторное открытие отчетов, как правило, требует много времени. И мне нужно время от времени получать статистику по архивам (то есть даты отчета, клиенты, средняя длина «открыта» и т. Д.). Я хочу использовать большой подход к данным, но я не уверен, использовать ли Hadoop, Cassandra или что-то еще? Может ли кто-нибудь предоставить мне некоторые рекомендации, как начать работу и решить, что использовать?Hadoop vs Cassandra: что лучше для следующего сценария?
ответ
Если вы архивируете большой, и вы хотите получать от него отчеты, вы не сможете использовать только Cassandra, так как у него нет простых средств для агрегирования данных. В итоге вы столкнетесь с Hadoop и Cassandra на тех же узлах.
Из архива моего опыта (пишите один раз - прочитайте много) не лучший вариант использования для Cassandra, если у вас много писем (мы попробовали его для бэкэнд для резервного sysyem). В зависимости от вашей стратегии уплотнения вы будете платить либо в космосе, либо в iops за это. Добавленные изменения распространяются через иерархии SSTable, что приводит к гораздо большему количеству записей, чем исходное изменение.
Невозможно ответить на ваш вопрос в полном объеме, не зная других переменных: сколько оборудования (серверов, их ram/cpu/hdd/ssd) вы собираетесь выделить? каков размер каждой записи «отчета»? сколько читает/пишет, что вы обычно ежедневно обслуживаете? Насколько велико ваше хранилище архивов?
Кассандра может работать нормально. Храните две таблицы, отчеты и отчеты. Определение схемы с использованием TTL от 24 часов и 7 лет:
CREATE TABLE reports (
...
) WITH default_time_to_live = 86400;
CREATE TABLE reports_archive (
...
) WITH default_time_to_live = 86400 * 365 * 7;
Используйте новое окно времени Уплотнительная стратегии (ТДП), чтобы свести к минимуму усиления записи. Было бы полезно хранить метаданные отчета и сообщать двоичные данные в отдельных таблицах.
Для анализа свертывания используйте Spark с Cassandra. Вы не указываете размер ваших данных, но примерно 1-3 ТБ на узел Кассандры должны работать нормально. Используя RF = 3, вам понадобится как минимум три узла.