Рекомендация для крупномасштабной системы хранения данных

Question

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

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

Я надеюсь, что некоторые SOER имеют опыт работы с таким программным обеспечением и могут дать рекомендации и / или указать на подводные камни.

В идеале я бы хотел развернуть это на EC2.

Answer 1

Ничего себе. Вы открываете огромную тему.

Несколько вещей прямо с моей головы ...

1. Тщательно продумайте свою схему для вставок в транзакционной части и прочитайте в отчетной части, лучше всего хранить их отдельно, если у вас действительно большие объемы данных
2. внимательно посмотрите на задержку, которую вы можете допустить между отчетами о транзакциях в реальном времени и агрегированными отчетами по историческим данным. Возможно, у вас должен быть процесс, который периодически запускается и объединяет ваши транзакции.
3. внимательно изучите любое требование, согласно которому вы будете отчитываться по вашим транзакционным и агрегированным данным, либо в одном отчете, либо в виде перехода от одного к другому
4. прототип с некоторыми значимыми запросами и некоторыми реалистичными объемами данных
5. получите реальное качество продукции, готовую к использованию базу данных, то есть Oracle / MSSQL
6. подумайте об использовании чужого кода / продукта для отчетности, например, Кристалл / BO / Cognos

как я сказал, огромная тема. По мере того, как я буду думать больше, я продолжу добавлять в свой список.

HTH и удачи

Answer 2

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

Если вы имеете дело с большим количеством запросов и большим временем обработки, вы бы использовали HDFS (формат распределенного хранилища в EC) для хранения ваших данных и запуска пакетных запросов (т.е. аналитики) на обычном оборудовании.

Затем вы предоставите столько экземпляров EC2, сколько необходимо (сотни или тысячи в зависимости от того, насколько велики ваши требования к обработке данных), и запустите карту, чтобы уменьшить количество запросов к вашим данным для создания отчетов.

Answer 3

@ Саймон сделал много отличных замечаний, я просто добавлю несколько и еще раз повторю / выделю некоторые другие:

1. Используйте правильный тип данных для меток времени - убедитесь, что СУБД имеет соответствующую точность.
2. Рассмотрите возможность очереди для захвата событий, позволяя нескольким потокам / процессам обрабатывать фактическое хранение событий.
3. Разделите схемы для вашего транзакционного хранилища и хранилища данных
4. Серьезно рассмотрите периодический ETL от транзакционной базы данных до хранилища данных.
5. Помните, что вы, вероятно, не будете иметь 50 транзакций в секунду 24x7x365 - пиковые транзакции против средних транзакций
6. Исследовать разбиение таблиц в СУБД. Oracle и MSSQL разделят значение (например, дату / время).
7. С самого начала имейте политику архивирования / хранения данных. Слишком много проектов просто начинают записывать данные без планов по их удалению / архивированию.

Answer 4

Ух ты .. Это огромная тема.

Позвольте мне начать с баз данных. Сначала получите что-то хорошее, если у вас будут сумасшедшие данные. Мне нравятся Оракул и Терадата.

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

Полагаю, вы можете подойти к этому двумя путями

• Бросьте деньги в проблему: купите лучшее в своем классе программное обеспечение (базы данных, программное обеспечение для отчетов) и наймите несколько умелых технических специалистов, которые помогут

• Используйте доморощенный подход: постройте только то, что вам нужно прямо сейчас, и вырастите все это органично. Начните с простой базы данных и создайте структуру веб-отчетности. Есть много инструментов с открытым исходным кодом и недорогих агентств, которые делают эту работу.

Что касается подхода EC2. Я не уверен, как это вписалось бы в стратегию хранения данных. Обработка ограничена, где EC2 является сильным. Ваша основная цель - эффективное хранение и восстановление.