Работа с гигабайтами данных

Question

Я собираюсь начать с нового проекта. Мне нужно иметь дело с сотнями гигабайт данных в приложении .NET. Сейчас очень рано рассказывать об этом проекте подробнее. Некоторый обзор следующий:

1. Много записей и много операций чтения в одних и тех же таблицах, в режиме реального времени
2. Масштабирование очень важно, так как клиент очень часто настаивает на расширении серверов баз данных, таким образом, серверы приложений также
3. Может быть реализовано предвидение, много-много использования с точки зрения совокупных запросов
4. Каждая строка данных может содержать множество атрибутов для работы с

Я предлагаю / имею в качестве решения следующее:

1. Использовать тип персистентности распределенной хеш-таблицы (не S3, а внутреннюю)
2. Используйте лайки Hadoop / Hive (любая замена в .NET?) Для любого аналитического процесса через узлы
3. Реализация графического интерфейса в ASP.NET/Silverlight (с большим количеством настроек, где это необходимо)

Что вы, ребята, думаете? Имею ли я здесь смысл?

Answer 1

«Предвидение, много и много использования с точки зрения совокупных запросов может быть реализовано»

Это отличительная черта хранилища данных.

Вот трюк с обработкой DW.

1. Данные являются плоскими. Факты и размеры. Минимальная структура, так как она в основном загружена и не обновляется.

2. Чтобы выполнить агрегирование, каждый запрос должен быть простым SELECT SUM() or COUNT() FROM fact JOIN dimension GROUP BY dimension attribute. Если вы сделаете это правильно, чтобы каждый запрос имел эту форму, производительность может быть очень, очень хорошей.

3. Данные могут храниться в виде простых файлов до тех пор, пока вы не захотите агрегировать. Затем вы загружаете данные, которые фактически собираются использовать люди, и создаете «datamart» из основного набора данных.

Нет ничего быстрее, чем простые плоские файлы . Вам не нужно каких-либо сложностей обрабатывать терабайты плоских файлов, которые (по мере необходимости) загружаются в дейтамарки СУБД для агрегирования и составления отчетов.

Простые массовые загрузки простых таблиц измерений и фактов могут быть ОЧЕНЬ быстрыми с использованием инструментов СУБД.

Вы можете тривиально предварительно назначить все ПК и ФК, используя сверхскоростную обработку плоских файлов. Это упрощает массовую загрузку.

Получите книги Ральфа Кимбалла по инструментам хранилища данных.

Answer 2

Являются ли ваши цели эффективностью, ремонтопригодностью, повышают шансы на успех, являются ли они самыми передовыми?

Не отказывайтесь от реляционных баз данных слишком рано. С внешним жестким диском за 100 долларов и генератором образцов данных (RedGate хорош), вы можете легко смоделировать такую ​​нагрузку.

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

Answer 3

Современные базы данных очень хорошо работают с гигабайтами. Когда вы попадаете в терабайты и петабайты, СУБД имеют тенденцию ломаться. Если вы предвидите такую ​​нагрузку, что-то вроде HBase или Cassandra может быть тем, что доктор прописал. Если нет, потратьте некоторое время на настройку базы данных, вставку слоев кэширования (memached) и т. Д.

Answer 4

Дайте СУРБД ответственность за сохранение целостности. И относитесь к этому проекту как к хранилищу данных. Держите все в чистоте, вам не нужно использовать множество сторонних инструментов: вместо этого используйте инструменты RDBMS. Я имею в виду, использовать все инструменты, которые есть в СУБД, и написать GUI, который извлекает все данные из БД, используя хорошо написанные хранимые процедуры хорошо спроектированной физической модели данных (индекс, разделы и т. Д.).

Teradata может обрабатывать много данных и является масштабируемой.

Answer 5

"много операций чтения и записи в одних и тех же таблицах в режиме реального времени" - важна ли целостность? Являются ли некоторые из этих записей транзакционными? Если это так, придерживайтесь СУРБД.

Масштабирование может быть сложным, но это не значит, что вы должны заниматься облачными вычислениями. Репликация в СУБД обычно делает свое дело, вместе с кластерами веб-приложений, балансировщиками нагрузки и т. Д.