Максимальное количество вставок базы данных в секунду

Я собираюсь разработать систему, которая будет получать очень много записей.

Есть ли фиксированный лимит на количество вставок, которые вы можете делать в базе данных в секунду?

Обычно мы используем сервер MS SQL, что лучше Oracle? Можно ли повысить производительность облачного решения без SQL?

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

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

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

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

Я провел тестирование на postgres, чтобы увидеть, как можно повысить производительность, сгруппировав мои вставки вместе. Например, вместо того, чтобы делать одну вставку за один раз, я вставляю несколько в большую строку sql, а затем запускаю этот sql.

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

Чего я не ожидал, так это результатов моих экспериментов. Я не уверен, как объяснить эти данные, поэтому, возможно, если есть кто-нибудь, кто знает об этом больше, они могут попытаться объяснить это.