Каковы стратегии для действительно быстрой базы данных одной таблицы?

Question

У меня есть база данных в SQL Server 2008, которая поддерживает различные приложения. Сейчас я начинаю разработку нового приложения, и из этой базы данных мне требуются данные, которые помещаются в одну таблицу (хотя есть некоторая репликация).

Данные, которые я хочу, могут быть извлечены в представление (несколько внутренних объединений) с 6 столбцами. Я разрабатываю веб-приложение, которое должно очень быстро перемещаться по данным (около 6 миллионов записей). Поэтому я хотел бы знать, целесообразно ли запрашивать представление SQL Server или развертывать новую обновляемую базу данных, проиндексированную Lucene или аналогичным механизмом (BerkeleyDB?)

Спасибо заранее!

Answer 1

Представления не упрощают доступ к вашим данным, они просто облегчают написание запросов. Это означает, что выбор данных в вашем представлении будет эквивалентен выполнению нескольких объединений, составляющих представление, и объединение в таблице, содержащей 6 миллионов записей, займет некоторое время.

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

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

Answer 2

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

На этом этапе рекомендуется запустить тест (возможно, нагрузочный тест JMeter jdbc ) для представления. Вы можете определить жизнеспособность самого простого решения с относительно небольшими усилиями, прежде чем идти по пути создания дополнительных индексов с Lucene или BerkeleyDB.

Answer 3

Вы знакомы с нормальными формами Бойса-Кодда ?

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

Например:

Скажем, у вас есть стол, people. У каждого человека есть manager_id, который связан с другим person в той же таблице, что и его manager. Вы можете добавить столбец для manager с именем employees_count, в котором хранится счетчик, который отслеживает, сколько людей находилось под этим manager.

Это простой, но эффективный пример ненормализованных данных