Методы оптимизации для больших баз данных

Вопрос немного расплывчатый, но вот несколько советов:

• Используйте подходящее оборудование для ваших баз данных. Я бы тоже выбрал 64-битную ОС.
• Имейте выделенные машины для БД. Используйте быстрые диски, настроенные для оптимальной производительности. Чем больше дисков вы можете охватить, тем выше производительность.
• Оптимизируйте БД для типа запросов, которые будут выполняться. Что происходит больше SELECT или INSERTs?
• Нагрузка происходит весь день или всего несколько часов? Можете ли вы отложить некоторые дела на ночь?
• Создавайте инкрементные резервные копии.
• Если вы рассмотрите Oracle вместо SQL Server, вы можете использовать такие функции, как Grid и Table Partitioning, которые могут значительно повысить производительность.
• Подумайте о том, чтобы иметь какое-нибудь решение для балансировки нагрузки между серверами БД.
• Предварительно спроектируйте схемы и таблицы, чтобы запросы выполнялись как можно быстрее. Также учитывайте соответствующие индексы.

Вам нужно будет более конкретно указать, как вы собираетесь хранить эти журналы. Являются ли они LOB в БД? Простые текстовые записи?

Я сам не использую его, но я читал, что можно использовать Hadoop в сочетании с hbase для распределенного хранения и распределенного анализа данных, таких как журналы.

Ссылка Дункана имеет хороший набор подсказок. Вот еще несколько советов:

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

Оптимизатор запросов SQL Server имеет оператор звездообразного преобразования. Если оптимизатор запросов повторно использует этот тип запроса, он может выбрать, какой фрагмент данных вы хотите, путем фильтрации на основе таблиц измерений, прежде чем он коснется таблицы фактов. Это уменьшает количество операций ввода-вывода, необходимых для запроса.

Для приложений VLDB, включающих сканирование больших таблиц, рассмотрите возможность хранения с прямым подключением с максимально возможным количеством контроллеров, а не SAN. Вы можете получить большую пропускную способность дешевле. Однако, если ваш набор данных меньше (скажем) 1 ТБ или около того, это, вероятно, не будет иметь большого значения.

64-битный сервер с большим количеством ОЗУ хорош для кэширования, если у вас есть ссылка на локальность в доступе к вашему запросу. Однако сканирование таблицы не имеет места ссылки, поэтому, когда он становится значительно больше, чем ОЗУ на вашем сервере, дополнительная память не так сильно помогает.

Если вы разбиваете таблицы фактов на разделы, подумайте о размещении каждого раздела на отдельном дисковом массиве или, по крайней мере, на отдельном канале SAS или SCSI, если у вас есть массивы SAS с репликацией портов. Обратите внимание, что это будет иметь значение только в том случае, если вы регулярно выполняете запросы по нескольким разделам.