У меня есть проект, который использует большую и растущую таблицу в базе данных PostgreSQL. Я использую PostgreSQL 11. У меня есть индекс (btree index) для столбца, который является подписью ha sh, которая должна быть уникальной. Эта БД растет, и мне нужно, чтобы она работала с огромным количеством данных, поскольку у меня ежедневно появляются миллионы (а иногда и десятки / сотни миллионов) новых записей, и в настоящее время я не хочу их удалять. Основной вариант использования - только вставка: мне просто нужно вставить записи и убедиться, что они не сталкиваются с сигнатурой ha sh другой записи.
Я делаю это с помощью команды COPY - я записываю свои данные в Пакеты (в настоящее время 10 000 записей в пакете, но это динамически c), а затем вставьте их в БД с помощью следующей команды:
COPY tableName FROM STDIN (FORMAT csv)
Я провел много тестов производительности на БД, и это было довольно приятно, я сначала заполнил его несколькими сотнями миллионов записей, а затем сделал пакетные вставки, одну многопоточную и многопоточную. Производительность колебалась в среднем от 0,3 до 0,5 мс на запись в партии, когда у меня было около 500 миллионов записей. Очевидно, что когда таблица довольно пуста, я получаю намного лучшие результаты, начиная с 0,01-0,02 мс на запись, и довольно стабильно на 0,2 мс на запись, когда у меня уже есть 150-200 миллионов записей.
Продолжил на моих тестах и попытался интегрировать это в мою большую программу, которая должна включать эту базу данных и вставки. Внезапно производительность большой таблицы упала, я начал видеть очень паршивую производительность, около 4 мс на запись в пакетном режиме. Я подумал, что это может быть из-за того, что я неправильно использовал проект в моей программе, но потом я вернулся только к вставке, и производительность отстой. Это очень странно, потому что иногда до 20 мс на запись в пакете, а иногда до 1-2 мс на запись в пакете. Затем я создал новую пустую таблицу с тем же индексом, заполнив ее простой командой COPY, как показано выше. Производительность была отличной, но после 180 миллионов записей эта таблица также внезапно «упала». Это не постоянный процесс, когда вы видите, что производительность ухудшается со временем. Просто внезапно получается очень плохая производительность.
В настоящее время у меня есть еще одна таблица, которой мне удалось заполнить почти 200 миллионов записей и производительность все еще отлично (около 0,1-0,2 мс на запись в пакете). Так что это кажется очень странным - это не сама БД, так как у меня есть две таблицы с очень похожими размерами, одинаковым индексом, одинаковыми шаблонами данных, и одна из них работает примерно в 10 раз хуже.
I Я использую симпатичный solid сервер для своей БД - 32 ГБ ОЗУ, большой ЦП, хранилище SSD, я не вижу своих вставок, даже используя все ЦП / ОЗУ.
Я понятия не имею, где проверьте решение, если бы вся БД давала плохую производительность, я бы сказал, что это имеет смысл, или если я достигал определенного количества записей в таблице, от которых производительность отстой.
Мне бы очень хотелось услышать любой совет о том, как подойти к этому. Если вам нужна дополнительная информация, пожалуйста, скажите мне.
Заранее спасибо