Проектирование баз данных для тяжелого записью веб-приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Optimising your database schema for writes rather than reads, as mentioned by many others, is your first point of call, although I guess you've been there already

Before investigating in-memory databases, you may want to have a look at some of the ORMs that are available, particularly NHibernate.

NHibernate keeps some data in memory and will allow you some control over when the data updates are 'flushed' from memory and sychronised with the database.

You might find it worth a look.

Изменить: сосредоточение строго на диске I /O...

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

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