База данных большого объема

Question

Мы создаем базу данных, в которой мы храним большое количество записей.Мы оцениваем миллионы (миллиарды за несколько лет) записей в одной таблице, и мы всегда ВСТАВЛЯЕМ и редко ОБНОВЛЯЕМ или УДАЛЯЕМ какую-либо запись.Это своего рода архивная система, в которую мы вставляем исторические записи ежедневно.Мы будем генерировать различные виды отчетов по этой исторической записи по запросу пользователя, поэтому у нас есть некоторые опасения и мы нуждаемся в технической помощи от вас, людей:

• Каков наилучший способ управления таблицами и базами данных такого типа?
• Какое влияние мы можем увидеть в будущем для очень большого стола?
• Есть ли ограничения на количество записей в одной таблице или размер таблицы?
• Как мы полагаем, чтобы вставить массовую запись из разных источников (в основном из листа Excel)?
• Каков наилучший способ индексирования больших таблиц данных?
• Какой лучшеORM (объектно-реляционное отображение) мы должны использовать в этом проекте?

Answer 1

Ваше последнее утверждение подводит итог. Не существует ORM, который бы хорошо справлялся с таким объемом данных и отчетными запросами: для этого вам помогут специалисты по SQL. Вы впервые услышали это здесь.

В противном случае

• На диске: файловые группы, разделы и т. Д.
• Сжатие менее используемых данных
• Требуются ли все данные? (Политика хранения данных)
• Нет ограничений на количество строк или размер таблицы
• ВСТАВИТЬ через промежуточные таблицы или промежуточные базы данных, очистить / вычистить / найти ключи, а затем перейти к основной таблице: НЕ загружать основную таблицу напрямую
• Столько оперативной памяти, сколько вы можете купить. Затем добавьте еще.
• Мало эффективных индексов
• У вас есть родительские таблицы или витрина данных? Есть FKs, но не используйте их (например, Bene Update / Delete в родительской таблице), поэтому индексы не нужны
• Использовать SAN (проще добавить дисковое пространство, больше томов и т. Д.)
• Нормализация

Некоторые из них основаны на нашем опыте прохождения около 10 миллиардов строк в одной из наших систем за 30 месяцев с пиками в 40 000 строк в секунду.

См. Это также для систем с большим объемом: 10 уроков от 35K TPS

Резюме: делай это правильно или не делай вообще ...

Answer 2

Миллиарды строк за «несколько лет» - не особо большой объем. SQL Server должен прекрасно с этим справляться - при условии, что ваш дизайн и реализация подходящие. Нет конкретных ограничений на размер стола. Придерживайтесь основательных принципов проектирования: нормализуйте свои таблицы, тщательно выбирайте ключи и типы данных и применяйте подходящую стратегию разделения и индексации.

Answer 3

Как лучше всего управлять такими таблицами и базами данных?

Если вы планируете хранить миллиарды записей, вам понадобится много дискового пространства, я бы порекомендовал 64-битную ОС под управлением SQL 2008 R2 и столько оперативной и жесткой памяти, сколько доступно. В зависимости от того, какая производительность вам нужна, у меня возникнет искушение взглянуть на SSD.

Какое влияние мы можем увидеть в будущем для очень большого стола?

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

Есть ли ограничения на количество записей в одной таблице или размер таблицы?

На правильной настройке, которую я описал выше, нет. Он ограничен только дисковым пространством.

Как мы предположим, чтобы вставить массовую запись из разных источников (в основном из листа Excel)?

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

Как лучше всего индексировать большие таблицы данных?

Индексируйте как можно меньше полей и оставляйте их только в числовых полях.

Какой лучший ORM (объектно-реляционное отображение) мы должны использовать в этом проекте?

Извините, не могу посоветовать здесь.