Проектирование базы данных для веб-приложения с большим количеством операций записи

Примите новое понятие «Все является сообщением, база данных — это резервная копия». Когда вам нужно что-то сохранить, создайте сообщение и отправьте его в черный ящик (например, eJabberD) ​​с помощью XMPP. Позвольте черному ящику обновлять вашу базу данных по собственному расписанию. Так работают такие сайты, как Twitter.

Взгляните на это слайд-шоу: http://www.slideshare.net/kellan/beyond-rest< /а>

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

Создайте две таблицы в своей базе данных для каждой таблицы, задействованной в этом потоке записи. Одна таблица должна быть вашей «живой» таблицей и должна быть максимально оптимизирована для записи (т. е. без индексов и никогда не считывается, кроме как при переходе к таблице для чтения). Другая ваша таблица должна быть вашей таблицей, оптимизированной для чтения, — проиндексирована соответствующим образом для любых соображений отчетности и т. д.

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

Вот странная идея: не использовать базу данных для первоначального захвата. Создайте два или три чрезвычайно быстрых индексированных файла, формат которых не нужно менять очень часто. Захват данных в этих файлах.

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

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

Не связано с программированием, но определенно поможет: купите несколько новых твердотельных дисков.

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

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

В противном случае обычные базы данных на основе файлов могут быть обмануты, заставляя их записывать свои файлы в файловую систему памяти, например tmpfs. .

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

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

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

На мой взгляд, вы должны быть в состоянии справиться со своей рабочей нагрузкой с помощью СУБД с кэш-памятью пользовательского размера. Я вижу порядка 10000 проиндексированных записей в секунду с помощью простой C++-вызываемой СУБД с обычным оборудованием. Это включает в себя фиксацию на диске. Кроме того, поскольку вы можете просматривать только одно маленькое поле в записи, ищите базу данных, ориентированную на столбцы — такую, которая хранит данные по столбцу. Нет смысла читать всю строку, если вас интересует только одно поле.

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

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

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

Возможно, вы найдете это достойным внимания.

Изменить: концентрация строго на дисковом вводе-выводе...

1. Вырвите как можно больше ненужных индексов. Индексы не приходят бесплатно — пространство ИЛИ время.
2. Удалите все специальные триггеры или ограничения, которые вам не нужны.
3. Удалите любые операторы связи сущностей/реляционной целостности, которые не являются абсолютно критическими.
4. Если ваша текущая СУБД поддерживает это, разделите таблицы транзакций на несколько дисков (например, циклическим перебором).
5. Рассмотрение возможности добавления дополнительных серверов баз данных, независимых друг от друга (т. е. без репликации); для этого вам нужен планировщик, чтобы решить, какой сервер примет транзакцию, и схема/отдельный процесс, который консолидирует транзакции.

Минимизация объема логики базы данных и добавление серверов в горизонтальном направлении (в отличие от передовых серверных технологий) — это, по сути, подход, принятый ebay.