Я рассматриваю возможность разработки системы, которая будет получать очень много записей.
Существует ли фиксированный лимит на количество вставок в базу данных в секунду?
Обычно мы используем сервер MS SQL, Oracle лучше? Можно ли добиться лучшей производительности на облачном решении No-SQL?
решение1
Я не знаю ни одной системы баз данных, которая имела бы искусственное ограничение на количество операций в секунду, и если бы я нашел такую, я бы был...бледный. Единственным ограничивающим фактором должны быть практические ограничения, накладываемые вашей ОС и оборудованием, в частности пропускная способность диска.
Остальная часть вашего вопроса (какая база данных "лучше") зависит от вашей реализации и требований. Если вы просто сбрасываете данные в корзину, то NoSQL-решение вродеMongoDBмогут быть подходящими, и их производительность может быть весьма впечатляющей. Если ваши данные в высокой степени реляционные, то системы СУРБД на основе SQL являются лучшим выбором.
При использовании любой СУБД на базе SQL вам придется потратить некоторое время на настройку системы для достижения оптимальной производительности. У поставщика вашей базы данных, скорее всего, будет целый ворох документации по этой теме, а разница между оптимально настроенной системой и той, которая была просто установлена на оборудовании, может быть существенной.
решение2
Я наткнулся на этот пост, когда искал ответ на вопрос, почему я вижу некоторые интересные результаты в некоторых моих собственных тестах производительности.
Я провел тестирование на postgres, чтобы увидеть, как можно повысить производительность, сгруппировав мои вставки вместе. Например, вместо того, чтобы делать одну вставку за раз, я вставляю несколько в большую строку sql, а затем запускаю этот sql.
Я знал, что приступая к тестированию, чем больше я буду держаться вместе, тем лучшей производительности я могу ожидать, поскольку накладные расходы начинают минимизироваться по сравнению с фактическими данными. Я также полагал, что производительность начнет снижаться в какой-то момент из-за накладных расходов, связанных с необходимостью повторной передачи, когда в такой длинной строке есть ошибка в одном бите.
Чего я не ожидал, так это результатов моих экспериментов. Я не уверен, как объяснить эти данные, так что, может быть, если есть кто-то, кто знает об этом больше, он может попытаться объяснить это.
