Поиск информации о построении крупных корпоративных систем

Question

Как вы организуете уровень БД, бизнес-логику и кроссплатформенный API вашей системы управления информацией, если загрузка и обработка 500000 записей данных за один сеанс является нормальной операцией (C # .NET 3.5 + MS SQL 2005)? *

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

У кого-нибудь есть идеи, в каком направлении копать?

• Проекты с открытым исходным кодом (не заботятся о языке или платформе, если это не Ook)
• книга
• Статья
• Google ключевые слова
• форумы или группы новостей

Любая помощь будет принята с благодарностью!

Обновление:

• простая подкачка (т. Е. Число в SQL 2005) не работает, т.к. много одновременных изменений в базу данных. Элемент, который удаляется или вставляется между запросами страницы, автоматически делает текущий индекс страницы недействительным.

Answer 1

Когда речь заходит об оптимизации БД для огромного количества данных, вы, скорее всего, выиграете от использования техники «BigTable». Я нашел статью здесь очень полезной. Вскоре идея состоит в том, чтобы использовать денормализацию БД для обмена дисковым пространством для повышения производительности.

Для разбивки на страницы в MS SQL 2005 вам потребуется больше информации об использовании функции ROW_NUMBER. Вот простой пример , вы найдете тонны из них с помощью Google (ключевые слова: ROW_NUMBER paging SQL 2005). Хотя не копайте слишком много - в реализации нет никакой магии, скорее в том, как вы собираетесь использовать / представлять саму пейджинг. Хороший пример - поиск в Google.

Примечание. Мы обнаружили, что поддержка нативной подкачки в платформе NHibernate недостаточна для нашего решения.

Также вам, вероятно, будет интересно создать индекс FULLTEXT и использовать полнотекстовый поиск. Вот статья MSDN о создании полнотекстового индекса и некоторая информация о полнотекстовом поиске.

Удачи.

Answer 2

Это хорошая книга для начала:

Шаблоны корпоративной архитектуры приложений . Автор Martin Fowler

Answer 3

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

В случае, если кому-то нужна информация:

• Страница продукта
• Политики действий по обработке исключений

Answer 4

То же самое с страницей SQL - она ​​не работает в сценарии многочисленных одновременные правки (как выявлено стресс-тестированием)

Как я уже говорил, в реализации подкачки нет ничего волшебного - вы либо используете ROW_NUMBER, либо временную таблицу. Волшебство здесь заключается в оценке наиболее распространенного сценария использования в реальном мире. Использование временной таблицы вместе с отслеживанием пользователя может немного помочь в преодолении сценария одновременного редактирования. Хотя я чувствую, что вы выиграете больше, ответив на вопросы:

1. Как долго пользователь остается на одной странице, прежде чем перейти на другую?
2. Как часто пользователь переходит с первой на любую другую страницу?
3. Какой общий счетчик страниц просматривает пользователь?
4. Насколько важно, если какая-то информация изменяется при переходе пользователя с одной страницы на другую и обратно?
5. Насколько важно, если какая-то информация удаляется, когда пользователь находится на странице, которая отображает эту информацию?

Старайтесь не концентрироваться на таких вопросах, как: «Как обрабатывать любые возможные сценарии одновременного редактирования во время подкачки страниц?», Прежде чем сначала ответить на вышеприведенные вопросы, а затем решать только те ситуации, которые действительно имеют значение.

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

P.S. Если этот ответ полезен, я объединю его с первым.

Answer 5

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

• Получение текстовых файлов, которые мы загружаем в базу данных Sybase.
• Отформатируйте различные каналы с помощью awk, чтобы они были в общем формате.
• Загрузите их в денормализованную промежуточную таблицу, используя bcp.
• Запуск хранимых процедур для заполнения нормализованной структуры базы данных.
• Исключить из денормализованной промежуточной таблицы.

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

Что-нибудь из этого полезно?

Answer 6

дандиков,

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

К сожалению, NHibernate ORM не вписывается в решение из-за увеличения производительности, которое оно добавляет. То же самое с подкачкой SQL - она ​​не работает в сценарии многочисленных одновременных изменений (как обнаружено стресс-тестированием )