Sqlite3 против Postgres vs Mysql - Rails

Я предполагаю, что это было поднято много раз, но я снова его воспитываю!!! В любом случае... В Ruby on Rails Sqlite3 уже настроен, и никаких дополнительных сборок и нарезки не требуется, но... после многочисленных чтений здесь и других мест, некоторые говорят, что это не масштабируемые, в то время как другие говорят, что на самом деле это может быть неплохо. Некоторые говорят, что MySQL намного лучше подходит для крупных проектов, в то время как другие думают, просто пойдите с PostgreSQL. Мне интересно услышать ваше мнение по этому поводу. В двух сценариях. Один из них, где вы начинаете небольшой сайт для публикации новостей, таких как новости CNN, и другой сценарий, в котором вы создаете сайт, похожий на Twitter?

Ответ 1

В значительной степени зависит ваше приложение.

Как правило, любая операция записи в базу данных sqlite выполняется медленно. Даже plain: update_attribute или: create может занимать до 0,5 секунды. Но если ваше приложение не пишет много (убийца против sqlite: пишите в БД по каждому запросу!), SQlite - отличный выбор для большинства веб-приложений. Доказано, что он обрабатывает небольшие и средние объемы трафика. Кроме того, это очень хороший выбор во время разработки, поскольку он нуждается в нулевой конфигурации. Он также очень хорошо работает в вашем testuite с режимом в памяти (за исключением того, что у вас тысячи миграций, так как он каждый раз восстанавливается с нуля). Кроме того, он в основном бесшовны для перехода от sqlite к, например, MySQL, если его производительность еще недостаточно.

В настоящее время MySQL - отличный выбор. Будущее расскажет, что происходит с MySQL под Oracle.

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

Ответ 2

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

Ответ 3

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

Тем не менее, SQLite3 не поддерживает все те типичные функции, которые имеет выделенный сервер SQL. Контроль доступа ограничен любыми файловыми разрешениями, которые вы можете установить для учетных записей UNIX на компьютере с вашим файлом базы данных, там нет демона, о котором можно говорить, а набор встроенных функций довольно мал. Кроме того, никаких хранимых процедур не существует, хотя вы можете эмулировать те, у которых есть представления и триггеры.

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

Ответ 4

ОТКАЗ:Мое мнение полностью предвзято, поскольку я использовал mysql, поскольку он впервые появился.

В этом вопросе возникает другой аргумент о том, как настроить среду разработки. Некоторые люди будут утверждать, что вы должны использовать те же самые дБм в разработке, что и при тестировании/производстве. Это полностью зависит от того, что вы делаете в первую очередь. Sqlite будет работать нормально, в разработке, в большинстве случаев.

Я лично участвовал в других сайтах, используя MySql и MsSql, чем Postgres.

Я участвовал в проекте, который очистил национальный список Do-Not-Call от номеров клиентов. Мы сохранили эти данные локально. У некоторых кодов областей есть более 5 миллионов записей. Приложение было первоначально написано в .Net с помощью MsSql. Это было "не так быстро". Я изменил его, чтобы использовать PHP и MySql (говорит Сад, прежде чем я узнал о Ruby). Он вставляет/переваривает 5 миллионов строк в (около) 3 секунд. Это было бесконечно быстрее, чем обработка его через MsSql. Мы также сохранили данные журнала вызовов в таблицах, которые вырастут до 20 миллионов записей менее чем за день. MySql обработал все, что мы бросили на него, как чемпион. Обработка, естественно, поразила, когда мы настраивали репликацию, но она была такой маленькой, что мы ее игнорировали.

Это действительно сводится к вашему проекту и какое решение соответствует потребностям проекта.