Выбрать СУБД между MySQL, PostgreSQL, MariaDB и MSSQL?

Добрый день! Я разрабатываю SaaS-приложение, и сейчас встал выбор СУБД для хранения основных данных. Начинал разработку на MySQL, но сейчас не уверен в выборе. Переезд на другую СУБД на данном этапе для меня не составит проблем (использую PDO). далек от ясного понимания что такое «высокие нагрузки» для СУБД. Просто по моим расчетам примерно через год база будет весьма увесистой (см. ниже)


Основной выбор стоит между MySQL, PostgreSQL, MariaDB. Также, возможен, но не приветствуется вариант Microsoft SQL Server на Windows Azure


Ситуация такова:
  1. Сложных запросов к базе нет. Максимум JOIN из двух таблиц
  2. Большая часть запросов — чтение
  3. Есть одна самая важная и «главная» таблица (структура таблицы ниже под спойлером). Таблица будет расти примерно на 10-30 тысяч записей в сутки. Запись данных в эту таблицу — самое главное!
  4. Большая часть запросов на чтение будет как раз к «главной» таблице. По этой таблице будет осуществляться поиск по любому из полей (в крайне редких случаях ~0.5% — по нескольким сразу). Поиск должен осуществляться быстро (не смотря на пункт №3)
  5. К «главной» таблице скорее всего будут добавлены индексы к каждому из полей сразу для двух полей (ownerID и Имя поля т.к. ownerID будет указан во всех запросах). Быстрый поиск будет нужен по любому из полей, но это не столь приоритетная задача. (Или лучше использовать Sphinx?)
  6. Львиная доля запросов (~80%) на чтение к «главной» таблице — простые select'ы по индексам from и personalID с limit = 20. Остальные запросы по любым другим полям по индексам (которых пока нет) ownerID и Имя поля, также с limit = 20
  7. Изменения данных в записях «главной» таблицы будут происходить крайне редко. Никакие записи из таблицы удаляться не будут.
  8. Поддержка транзакций и внешних ключей не обязательна
  9. Нужна возможность репликации данных типа master-slave
  10. Возможность шардинга на уровне СУБД приветствуется
  11. Крайне важна надежность БД (т.е. такой крах, как у MyISAM с ручным восстановлением сразу отпадает)
  12. К «главной» таблице могут добавляться новые поля. Это конечно крайне редкое явление и далеко не самое важное требование, но добавление нового столбца к таблице размером с десяток ГБ для MySQL весьма длительный процесс, а выносить новые поля в отдельную таблицу очень не хочется
  13. Всё это по-началу будет крутиться на таком вот выделенном сервере
  14. Другие таблицы будут расти медленно, и обращения к ним будут достаточно редкими, за них я не переживаю. Часто обновляемые данные у меня крутятся в redis'e

Структура «главной» таблицы
CREATE TABLE IF NOT EXISTS `clients` (
  `id` bigint(11) NOT NULL AUTO_INCREMENT,
  `personalID` int(11) NOT NULL,
  `ownerID` int(11) NOT NULL,
  `fromID` int(11) NOT NULL DEFAULT '4',
  `fromDomain` varchar(255) NOT NULL,
  `datetime` datetime NOT NULL,
  `status` int(11) NOT NULL DEFAULT '0',
  `paid` tinyint(1) NOT NULL DEFAULT '0',
  `paymentType` tinyint(4) NOT NULL DEFAULT '1',
  `wmSum` float NOT NULL DEFAULT '0',
  `wmCommission` float NOT NULL DEFAULT '20',
  `sysNumber` varchar(14) NOT NULL,
  `sysNumberLastUpdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `sysNumberStatus` varchar(250) NOT NULL,
  `timezone` float NOT NULL,
  `comment` varchar(500) NOT NULL,
  `countryID` int(11) NOT NULL,
  `postIndex` varchar(6) NOT NULL,
  `region` varchar(500) NOT NULL,
  `city` varchar(500) NOT NULL,
  `address` varchar(500) NOT NULL,
  `fio` varchar(500) NOT NULL,
  `phone` varchar(15) NOT NULL,
  `email` varchar(255) NOT NULL,
  `price` float NOT NULL,
  `quantity` int(11) NOT NULL DEFAULT '1',
  `label` varchar(30) NOT NULL,
  `tag` int(11) NOT NULL,
  `ip` varchar(15) NOT NULL,
  `referer` varchar(200) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `from` (`ownerID`,`fromID`),
  KEY `paid` (`paid`),
  KEY `status` (`status`),
  KEY `label` (`label`),
  KEY `sysNumberLastUpdate` (`sysNumberLastUpdate`),
  KEY `personalID` (`ownerID`,`personalID`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;



P.S. Желающих отправить меня гуглить прошу даже не отвечать. Найти информацию по сравнению актуальных версий разных СУБД мне не удалось, а изучать возможности, плюсы и минусы PostgreSQL, Microsoft SQL Server и MariaDB для человека, который с ними не работал весьма долгая задача. Да и в MySQL я далеко не эксперт, и подобный крупный проект для меня дело новое, да и возможности MySQL от версии к версии отличаются. Единственное, что я точно знаю, так это то, что таблицы типа MyISAM в MySQL мне точно не подойдут
  • Вопрос задан
  • 46153 просмотра
Решения вопроса 1
KEKSOV
@KEKSOV
Похоже, что Вы забыли рассмотреть еще вот этот вариант: Percona Server is an enhanced, drop-in MySQL replacement. Для очень быстрого выполнения запросов необходимо воспользоваться special NoSQL interface called HandlerSocket. Да, и даже multi-master репликация там тоже есть.

Несколько смущает PDO и желание сделать нагруженный сайт. Боюсь, что от этой прослойки придется отказаться сразу.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
EugeneOZ
@EugeneOZ
Шардится и реплицируется Postgre проще и надёжнее. Но даже с учётом PDO, есть разница местами в синтаксисе и возможностях между ней и MySQL.
Главное — не вляпайтесь в MSSQL. С ним можно нормально работать только внутри стека MS-инструментов. Оно даже UTF-8 не поддерживает. Ну и MS кладёт болт на не-виндовые драйвера, выпускают их очень редко.
Ответ написан
@frantic
Выбирайте то, что знаете лучше!

Если MySQL, то рассмотрите MariaDB или Percona. Да и на них вы сможете переехать с MySQL в любое время, так как они обратно совместимы.
Судя по вашим данным, вопрос нагрузки при учете прямых рук, возникнет перед вами года через два-три. А преждевременная оптимизация может погубить проект.

И постарайтесь максимально отказаться от JOIN'ов. Как правило из-за них возникает большинство проблем.
Ответ написан
Комментировать
afiskon
@afiskon
Тут есть про MySQL, MariaDB и PostgreSQL. Надеюсь, хотя бы частично ответит на ваш вопрос eax.me/postgresql-vs-mysql/
Ответ написан
Комментировать
alexhemp
@alexhemp
А почему не посмотрите на MongoDB?
Это конечно не ACID база данных, но зато горизонтальное масштабирование/шардинг гораздо проще делать.
Ответ написан
@Mirocow
MongoDB
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы