Подходит ли MySQL для тяжелой базы данных с 3,5 млн. Строк? Если да, то какой двигатель?

Question

Мой опыт работы с базами данных связан с довольно небольшими веб-приложениями, но сейчас я работаю с набором данных об избирателях для всего штата. Число избирателей составляет около 3,5 млн., И мне нужно будет немного рассказать о них, основываясь на их адресе, истории голосования, возрасте и т. Д. Само веб-приложение будет написано на Django, поэтому у меня есть несколько вариантов базы данных, включая MySQL и PostgreSQL.

В прошлом я почти исключительно использовал MySQL, так как он был так легко доступен. Я понимаю, что 3,5-метровые строки в таблице не так уж и много, но это самый большой набор данных, с которым я лично работал, поэтому я не в своей личной зоне комфорта. Кроме того, этот проект не является быстродействующим одноразовым приложением, поэтому я хочу убедиться, что я выбрал лучшую базу данных для работы, а не ту, с которой мне удобнее всего.

Если MySQL является подходящим инструментом для работы, я также хотел бы знать, имеет ли смысл использовать InnoDB или MyISAM. Я понимаю основные различия между ними, но некоторые источники говорят, что для скорости используют MyISAM, но InnoDB, если вам нужна «реальная» база данных, в то время как другие говорят, что все современные применения MySQL должны использовать InnoDB.

Спасибо!

Answer 1

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

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

Answer 2

MyISAM имеет смысл, только если вам так нужна скорость, что вы готовы принять множество недостатков целостности данных для ее достижения. Вы можете получить повреждение базы данных при любом нечистом завершении работы, нет внешних ключей , нет транзакций , оно действительно ограничено. А так как 3,5 миллиона строк на современном оборудовании - это тривиальный набор данных (если только ваши строки не огромны), вы, безусловно, не в той точке, где вы вынуждены оптимизировать производительность вместо надежности, потому что другого способа повлиять на производительность нет. цели - это единственная ситуация, когда вам придется мириться с MyISAM.

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

Мне не нравится MySQL, потому что существует так много способов, с помощью которых вы можете помещать неверные данные в базу данных, когда PostgreSQL не терпит такого поведения (см. Сравнение скорости и надежности ), плохое поведение MyISAM просто подмножество проблем там. Учитывая то, насколько сейчас раздроблено сообщество MySQL, и неопределенность в отношении того, что Oracle собирается с ним делать, вы можете рассмотреть возможность взглянуть на PostgreSQL, чтобы у вас было больше возможностей здесь в будущем. В последнее время вокруг PostgreSQL, всегда имеющего свободную лицензию BSD, гораздо меньше драматизма, и, хотя, по крайней мере, по крайней мере все сообщество разработчиков для него движется в том же направлении.

Answer 3

Поскольку это таблица для чтения, я рекомендую использовать тип таблицы MyISAM. Если вы не используете внешние ключи, вы можете избежать ошибок типа this и that .

Резервное копирование или копирование таблицы на другой сервер так же просто, как копирование файлов frm, MYI и MYD.

Answer 4

Если вам нужно вычислять отчеты и сложные агрегаты, имейте в виду, что оптимизатор запросов postgres довольно умный и изобретательный, а mysql «оптимизатор» довольно прост и глуп

При большом соединении разница может быть огромной.

Единственное преимущество MySQL состоит в том, что он может работать с индексами, не обращаясь к таблицам.

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