Оригинальная версия MySQL была разработана фино-шведской компанией MySQL AB, которую основали Джвид Ахмарк, Аллан Ларссон и Майкл Монти. Первая версия MySQL появилась в 1995 году. Изначально она предназначалась для личного пользования, но спустя несколько лет превратилась в базу данных корпоративного уровня.
В январе 2008 Sun Microsystems приобрела MySQL AB за 1 миллиард долларов. Вскоре после этого, Oracle купила Sun Microsystems с разрешения Европейской комиссии, которая изначально опасалась, что такое решение повредить свободному проекту MySQL, поскольку он был прямым конкурентом СУБД Oracle. Из-за недоверия к стратегии развития MySQL был создан форк под названием MariaDB.
Шли годы и за это время MariaDB начала использоваться во многих дистрибутивах Linux по умолчанию. Она используется для обеспечения работы большинства сайтов интернета. В этой статье мы попытаемся выполнить сравнение MySQL vs MariaDB и разобраться почему вторая лучше первой и когда нужна именно оригинальная MySQL.
В отличие от многих других проектов с открытым исходным кодом полученных от Sun Microsystems, Oracle до сих пор развивает MySQL. После того как много разработчиков подали в отставку, были наняты новые люди. Но разработка новых версий MySQL ведется закрыто. Исходный код доступен только команде разработчиков и выгружается в публичный репозиторий только после завершения работы. Все решения обсуждаются внутри компании
MariaDB разрабатывается полностью открыто, все решения и новые идеи касаемо развития могут свободно обсуждаться в email рассылке, а также системе сообщений об ошибках. Помочь в разработке MariaDB очень легко, патчи от пользователей принимаются также, как и от разработчиков. В целом MariaDB развивается более активно.
Из-за раскрученности бренда у MySQL все еще есть большое сообщество, но все больше и больше проектов переходят на MariaDB. Такие известные корпоративные дистрибутивы, как REHL 7 и SLES 12 уже используют MariaDB, а это значит, что в сражении MySQL или MariaDB победит последняя.
2. Частота релизов
Политика Oracle - выпускать обновления безопасности для всех своих продуктов каждые три месяца. Но выход новой версии MySQL запланирован каждые два месяца. Это часто приводит к тому, что обновления продукта и обновления безопасности не синхронизируются.
Разработчики не успевают закрыть все сообщения об ошибках и уязвимости, в результате чего база данных может оставаться уязвимой несколько месяцев. Еще одна проблема MySQL в том, что обновления безопасности очень расплывчаты. Если администратор не может просто обновить программу до новой версии, то создать бэкпорт сложно.
MariaDB выпускает обновления программы и обновления безопасности синхронизировано, поэтому все ошибки успевают исправить. Все исправленные CVE задокументированы и любой пользователь может узнать что изменилось в новой версии.
4. Возможности и функциональность
В целом MariaDB развивается быстрее и имеет больше возможностей. Эти возможности касаются оптимизации, улучшения работы с памятью, и много другого. Обычно, со временем, эти возможности переносятся в MySQL. Например, та же поддержка GIS появилась в MariaDB раньше, чем в MySQL. Среди прочего MariaDB имеет множество улучшений производительности Inodb, MyISAM и движка обработки запросов, поддерживает GIS, ликвидацию таблиц, виртуальные и динамические колонки, репликацию с несколькими источниками, роли и многое другое.
Но у MariaDB есть и свои минусы, она не поддерживает некоторые возможности, которые есть в MySQL. А именно, MariaDB несовместима с синтаксисом JSON MySQL, не поддерживаются плагины ngram, MeCab, MySQL X, а также пространства таблиц, которые позволяют присваивать данные нескольким таблицам одновременно. Но разработчики активно работают над исправлением недостатков.
Для тех, кого интересуют кластеры MySQL будет интересно то, что в MariaDB используется новая система репликации Galera, прием ее работа отличается от стандартного master-salve. Galera разрабатывается с 2007 года, но она никогда не включалась в официальную версию MySQL.
5. Поддержка движков хранения данных
Система управления базами данных MariaDB поддерживает намного больше движков для хранения данных. Большинство этих движков доступны в качестве плагинов для MySQL, но в MariaDB они включены в официальный релиз. Это означает, что движки правильно интегрированы и будут хорошо работать. Вот список поддерживаемых движков:
- Aria;
- XtraDB - улучшенная версия InnoDB;
- FederatedX - улучшенная версия Federated;
- OQGRAPH;
- SphinxSE;
- IBMDB2I;
- TokuDB;
- Cassandra;
- CONNECT;
- SEQUENCE;
- Spider;
- ColumnStore;
- MySIAM.
Напомню, что оригинальная MySQL поддерживает по умолчанию только три типа таблиц - Aria, MySIAM и InnoDB. Это важный аспект в выборе MySQL или MariaDB.
6. Имя и нумерация версий
Эти отличия MariaDB от MySQL не столь важны, но, возможно, они будут кому-то интересными. Имя MySQL было дано в честь первой дочери одного из разработчиков - Майкл Монти, ее зовут My. Разработку MariaDB продолжил тот же человек и на этот раз программа была названа в честь его младшей дочери - Марии.
Что касается версий, то изначально, до версии 5.6 версии MariaDB нумеровались синхронно до версий MySQL, на которых они были основаны. Но когда накопилось достаточно изменений и за основу стал браться код MariaDB номера версий было принято поменять на 10. С того момента нумерация MariaDB выполняется только так.
Выводы
В этой статье мы сделали сравнение MySQL vs MariaDB. По большинству параметров MariaDB намного лучше, чем MySQL, поэтому не зря большинство дистрибутивов Linux теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.
Которая вскоре была сама куплена Oracle). Это довольно оправданные сомнения, о которых я поговорю немного позже. Кроме своей роли "упрощенной версии" MySQL, MariaBD также обладает несколькими новыми функциями, которые, по мнению некоторых, делают её лучше MySQL.
Перед тем как подробно рассказывать об этих функциях, я хочу поговорить о схеме нумерации версий MariaDB. Во-первых, её версии совпадают с версиями MySQL - так, например, в MariaDB 5.1 используется та же кодовая база, что и в MySQL 5.1. По мере обновления и добавления исправлений к исходному дереву MySQL к MariaDB будут по возможности добавляться такие же патчи (теоретически, производятся ежемесячные слияния с кодом MySQL). Но если новые и уникальные функции постоянно добавляются, представляю, что поддерживание такого рода равенства кодов стало ночным кошмаром.
Команда разработчиков MariaDB, должно быть, знают об этом, так как они решили использовать новую схему нумерации. Самая новая версия MariDB (которая всё ещё является альфа-версией) - Maria 10.0, за которой следует младший номер устройства:
Mysql -P 3406 -u root -p Enter password: ******** Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 1 Server version: 10.0.2-MariaDB mariadb.org binary distribution Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. Type "help;" or "\h" for help. Type "\c" to clear the current input statement. MariaDB [(none)]> select version(); +------+ | version() | +------+ | 10.0.2-MariaDB | +------+ 1 row in set (0.01 sec) MariaDB [(none)]>
Люди, работающие над MariaDB, дают длинное и довольно пространное объяснение, почему они так сделали - что всё ещё разочаровывает некоторых разработчиков - но что есть, то есть. Они не могут продолжать добавлять новые функции и постоянно утверждать, что это ускоренная, полностью совместимая с MySQL версия.
Так что за новые функции? Давайте рассмотрим парочку из них.
Движок Cassandra
Одной из уникальных функций MariaDB является её движок для соединения с серверной версией СУБД Cassandra. Сам движок является просто посредником, который соединяется с сервером Cassandra, запущенным отдельно. Cassandra - это NoSQL хранилище данных, которое изначально было создано для Facebook , а затем стало проектом Apache ; хотя оно и может использоваться в кластерах без единой точки отказа, оно всё ещё не является совместимым с ACID. Вообще, если вы собираетесь использовать Cassandra в качестве движка, не ожидайте такой же скорости производительности, как у InnoDB или ExtraBD.
Но вы можете получить доступ к информации с помощью MySQL, добавив интерфейс, похожий на SQL , а также допуская в какой-то степени выборки, вставки, обновления, удаления и даже присоединения. Однако команда MariaDB утвержает, что движок Cassandra лучше не использовать для чего-то более существенного, чем простое использование данных.
Так что эта функция может быть полезной, если вы... мм... дайте подумать... ну...
Если вы пишете программное приложение, которое требует доступа к данным в Cassandra, тогда вам, возможно, лучше использовать встроенный Cassandra API, а не MySQL. Полагаю, что если вы мучаетесь с интерфейсом командной строки MySQL и нужно взять кое-какие данные, то Cassandra может оказаться полезной - но если вы собираетесь воспользоваться этим, то не проще ли помучаться с интерфейсом командной строки Cassandra?
Так что я на самом деле не очень уверен в данном варианте использования, но именно это умерило энтузиазм по поводу данной функции у некоторых людей в блогосфере .
Движок OQGraph
Не буду слишком много о нём рассказывать, так как идея та же, что и в Cassandra: движок является просто интерфейсом вычислительного движка Open Query Graph (хранилища для организации сложных графов). Это может помочь в некоторых специализированных приложениях, хотя адаптация структур графов к SQL формату является на первый взгляд немного странной.
Одним важным улучшением, что делает MariaDB более мощной, является использование XtraDB в качестве ускоренного замещения InnoDB. Но XtraDB добавляет новые возможности масштабирования, в которых нуждаются современные приложения - и именно в этом заключается главное отличие. Oracle утверждает, что на данный момент MySQL масштабирует лучше, чем когда-либо раньше. Возможно, это так и есть, но она хороша так же, как и её движок. А если движок на практике не масштабирует так, как следует, то и MySQL не сможет сделать этого лучше.
Режим атомарной записи
Одной из главных причин, почему следует выбирать реляционную базу данных, а не обычную NoSQL, является то, что реляционная база полностью совместима с ACID. Проще говоря, если возникает какая-либо ошибка, никто не хочет, чтобы все данные исчезли. И хотя на компьютерах разработчиков ошибки - явление не частое, они всё ещё происходят во многих IT центрах. На данный момент, стандартный InnoDB/XtraDB движок для записи данных использует двойную буферизацию , чтобы гарантировать успешную запись данных в случае какого-либо сбоя. Как бы то ни было, при работе с высокоскоростными SSD устройствами (возьмём в качестве примера), двойной буфер может плохо сказаться на производительности, не давая вам возможности использовать всю скорость SSD. Какое решение? Вы можете выбрать один буфер и воспользоваться режимом атомарной записи (Atomic Writes). Попробуйте на свой страх и риск и, лучше не на производстве.
Повторюсь, функция интересная, но не настолько, чтобы убедить вас забросить MySQL и перейти на MariaDB.
Сравнение производительности MySQL и MariaDB
А сейчас я хочу обратить ваше внимание на сравнительные тесты, проведенные командой MariaDB, и добавить кое-какие комментарии. В этом блоге выдвинута интересная точка зрения: если потоков меньше 16, MySQL работает хорошо, а если их количество больше - хотя, конечно, производительность продолжает немного расти, но не так хорошо, как в других версиях, с которыми её сравнивали (включая MariaDB-5.5.28a и MariaDB-10.0.1; посмотрите график теста производительности в начале этой статьи). Это довольно часто встречающаяся проблема в параллельном программировании при попытке ориентации на несколько ядер и потоков внутри ядра. Если построенные алгоритмы верны, то вы будете ощущать преимущества по мере увеличения ядер. Проблема в том, что вам придётся использовать в своём параллельном программировании 2 метода: 1) многопотоковый на нескольких ядрах и 2) векторизацию. Эти методы являются двумя сторонами нынешнего многоядерного программирования, и ваш код должен корректно их использовать.
Одним из наиболее распространённых результатов неправильного кодирования является то, что вы будете наблюдать прирост производительности при работе с первыми 8 или 16 потоками, после чего никакого улучшения наблюдаться не будет. Если у вас возникла такая проблема, то скорее всего дело в алгоритмах. И это будет в случае или с гиперпотоками, или с аппаратными потоками. Это именно то, что мы наблюдаем в тестах MySQL. Для меня это означает наличие проблем с масштабированием в MySQL, и это повод задуматься. В том же тесте у MariaDB также наблюдались некоторые проблемы, т.к. производительность уменьшалась, но незначительно; я предполагаю, что это не касается параллельных алгоритмов.
Также я не знаю, насколько хорошо некоторые версии подходили к компьютерам, которые использовались для проведения теста. При компиляции Intel-кода, вам нужно, чтобы компилятор генерировал SIMD-код размера, подходящего для целевой машины. В случае несоответствия вы не получите ожидаемой производительности от вашего кода векторизации. Чтобы сделать это правильно, вам потребуется вставить в код нужные прагмы, затем правильно написать алгоритмы векторизации и, наконец, запустить соответствующие опции компилятора. Знаю, звучит глупо, но я видел программы, изданные с неправильными опциями чаще, чем вы думаете. В любом случае, чистый MySQL-код не был так оптимизирован для поддержки многоядерности и векторизации, как MariaDB.
Больше всего мне хотелось бы увидеть разновидность или MySQL, или MariaDB, скомпилированную специально для сопроцессора Intel Xeon Phi, где код разгружает 61-ядерный cопроцессор, а кто-то пытается раскрутить все 244 потока. К сожалению, у меня нет доступа к такой машине. Также, если вы хотите узнать больше о векторизации и параллельном кодировании, почитайте последнюю книгу сотрудников Intel Джеймса Джефферса (James Jeffers) и Джеймса Райндерса (James Reinders) "Высокопроизводительное программирование для сопроцессора Intel Xeon Phi".
Следует ли переходить?
Очевидно, что новые функции MariaDB не такие уж и волшебные - вам, возможно, потребуется доступ к некоторым данным Cassandra, но сомневаюсь, что для этого вы воспользуетесь MySQL. То же самое относится и к другим движкам на данной платформе. Производительность MariaDB немного выше на многоядерных компьютерах, однако, полагаю, что под это можно настроить и MySQL.
Так следует ли переходить на MariaDB?
Во-первых, продумайте всевозможные риски (руководители высшего звена любят слушать про риск и пользу). Если вы перейдёте на MariaDB, возможно, вы начнёте пользоваться функциями, доступными только для MariaDB (что пока что маловероятно), а затем окажется, что вернуться назад к MySQL, не приложив усилий, не получится. Но осмелюсь предположить, что это не такой уж и риск, если учесть некоторые более масштабные проблемы.
Поразмышляйте над всеми вопросами насчёт Oracle и её планами по лицензированию MySQL. MySQL с открытыми исходниками идёт вразрез с патентованными и очень конкурентными программами. Только это является поводом для размышлений - будет ли Oracle что-либо предпринимать, чтобы как-то помешать разработке MySQL? Некоторые утверждают , что это уже происходит.
А что насчёт совместимости MySQL и MariaDB? Команда MariaDB усердно работает над тем, чтобы сделать базу данных полностью совместимой с MySQL, и они продолжают устранять ошибки в исходнике. Однако новые функции (а также схема нумерации версий) предполагают, что, несмотря на все усилия, обе платформы будут сильно различаться.
Если Oracle добавит к MySQL некоторые новые функции, которые не поддерживаются MariaDB, то очевидно, что они не будут доступными для вас. А если вы будете пользоваться функциями, отсутствующими в MySQL, вы не сможете обратно на него перейти, учитывая, что у вас были причины перейти на другую платформу. MariaDB подаёт все признаки того, что она довольно долгое время будет в ходу, что нельзя сказать о MySQL. Другими словами, даже если новые функции MariaDB могут и не быть полезными для всех, на мой взгляд, существует более чем достаточно причин, чтобы отказаться от MySQL и полностью перейти на MariaDB.
Одна маленькая ремарка перед тем, как я закончу. Некоторые блоггеры подняли хороший вопрос по поводу соглашений об обслуживании. Если кто-либо из сотрудников вашей компании взял и купил у Oracle соглашение об обслуживании, чтобы помочь вам с MySQL, возможно, чтобы избежать финансовых и правовых вопросов, возникающих при нарушении договора, вам не захочется переходить на MariaDB. Кроме этой, я больше не вижу веских причин, чтобы продолжать пользоваться MySQL.
MariaDB - Desarrollador Monty Program Ab http://mariadb.org Información general Lanzamiento 22 de enero de 2009 … Wikipedia Español
MariaDB - Entwickler Monty Program AB (bis Februar 2008: MySQL AB, bis Januar 2010: Sun Microsystems) Aktuelle Version MariaDB 5.2.6 (12. Mai 2011) Betriebssystem Unix, Linux, Windows … Deutsch Wikipedia
MariaDB - Environnements Unix, Windows, Solaris Type système de gestion de base de données … Wikipédia en Français
MariaDB - Developer(s) Monty Program Ab Initial release 22 January 2009 (2009 01 22) Stable release 5.2.9 (September 22, 2011; 5 … Wikipedia
MySQL - Developer(s) MySQL AB (A subsidiary of Oracle) Initial release May 23, 1995 (1995 05 23 … Wikipedia
Comparison of relational database management systems - Programming language comparisons General comparison Basic syntax Basic instructions Arrays Associative arrays String operations … Wikipedia
Michael Widenius - Ulf Michael Widenius Michael Monty Widenius Born March 3, 1962 (1962 03 03) (age 49) Helsinki, Finland … Wikipedia
Percona XtraDB Тип СУБД (Storage Engine для MySQL) Первый выпуск 16.12.2008 Последняя версия 10.1 (16.05.2010) Лицензия GPLv2 Сайт … Википедия
HeidiSQL - The main view of an active session in HeidiSQL, with MySQL Databases (left) and contained Tables (right) … Wikipedia
Fork (software development) - In software engineering, a project fork happens when developers take a legal copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term implies a split in the developer… … Wikipedia
Книги
- Базы данных. Практическое применение СУБД SQL и NoSOL-типа для применения проектирования информационных систем
- Базы данных. Практическое применение СУБД SQL и NoSOL-типа для применения проектирования информационных систем. Гриф МО РФ , Мартишин С.А.. Учебное пособие предназначено для изучения практического применения СУБД SQL и NoSQL-типа при проектировании информационных систем. Проведены аналогии между базами данных SQL и NoSQL-типа.…
Послужила необходимость обеспечения свободного статуса СУБД (под лицензией GPL), в противовес неопределенной политике лицензирования MySQL компанией Oracle . Продукт распространяется и используется согласно лицензии GNU GPL v.2, GNU LGPL.
Система написана с использованием: C, C++, Perl, Bash. Продукт работает под управлением ОС Linux и UNIX -подобных, Windows .
2014: MariaDB Enterprise 1.0
Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с полностью открытым и прозрачным процессом разработки, не зависящим от отдельных вендоров. MariaDB поставляется вместо MySQL во многих дистрибутивах Linux (RHEL 7 , SUSE 12 , Fedora , openSUSE , Slackware, OpenMandriva, ROSA , Arch Linux, Debian 9). Система внедрена в проектах: Wikipedia , Google Cloud SQL и Nimbuzz.
Основные улучшения MariaDB 10.1
- Поддержка шифрования таблиц и логов транзакций, которое позволяет защититься от утечки данных в случае кражи жесткого диска , но бесполезно в ситуации получения контроля над работающей СУБД , например, в результате атаки через подстановку SQL-запроса или взлома системы. При включении шифрования накладные расходы увеличиваются на 3-5%. Ключи шифрования имеет смысл хранить на отдельном защищённом сервере с включением системы ротации ключей, подразумевающей периодическое перешифрование с новым ключом после устаревания текущего ключа. Поддержка шифрования реализована в хранилищах XtraDB и InnoDB. Предлагается несколько схем: шифрование выбранных таблиц, шифрование всех таблиц в БД и шифрование всех таблиц за исключением выбранных. Благодаря шифрованию лога транзакций защита также обеспечивается в системах с репликацией;
- Включение в базовую поставку технологии синхронной multi-master (active-active) репликации Galera, ранее предлагаемой в рамках отдельного продукта MariaDB Galera Cluster. Galera расширяет возможности СУБД MariaDB средствами синхронной репликации, при которой все узлы всегда содержат актуальные данные, т.е. гарантируется отсутствие потерянных транзакций, так как транзакция фиксируется только после распространения данных по всем узлам. При этом, в рамках транзакции операции выполняются сразу, задержка из-за ожидания подтверждения возникает только при выполнении операции "commit". Репликация выполняется в параллельном режиме, на уровне строк, с передачей только информации об изменениях. Управление принадлежностью узлов кластеру выполняется автоматически, сбойные узлы сразу исключаются из кластера без участия администратора, новые узлы при необходимости можно подключить на лету без дополнительной переконфигурации;
- Возможность репликации данных c MySQL 5.6 при включении на MySQL поддержки GTID, т.е. MySQL теперь может использоваться в роли master-сервера для MariaDB. Указанная возможность позволяет существенно упростить тестирование в процессе миграции с MySQL на MariaDB;
- Поддержка сжатия страниц данных для хранилищ InnoDB и XtraDB. От ранее доступного механизма сжатия (row_format=compressed) новый метод отличается возможностью выбора различных алгоритмов сжатия (zlib, lz4, lz0, lzma, bzip2 и snappy) и иной организацией процесса работы с упакованными данными. Если в традиционной реализации в буфере находятся как сжатые, так и ещё не упакованные данные, то новая схема подразумевает нахождение в буфере только распакованных данных - страницы сжимаются перед записью в хранилище и распаковываются после чтения. Новый метод наиболее эффективен при использовании SSD -накопителей или NVM-памяти. Наилучшие результаты наблюдаются при использовании плат FusionIO;
- Реализована система дефрагментации хранилищ InnoDB, основанная на наработках, предоставленных компанией Facebook . Ранее, при удалении строк из InnoDB они лишь помечались удалёнными и становились доступны для новых записей без фактического освобождения блоков на диске и без возвращения дискового пространства системе. Выполнение "OPTIMIZE TABLE" решает указанную проблему, но путём полного перестроения таблицы с копированием имеющихся данных на новое место, т.е. требует наличия большого объёма свободного дискового пространства. После включения в файле конфигурации поддержки дефрагментации (innodb-defragment=1), выполнение команды "OPTIMIZE TABLE" не приводит к копированию в новые таблицы, а реализуется через механизм перемещения записей;
- Реализован "оптимистичный" режим параллельной репликации, который значительно упрощён по сравнению с появившимися в MariaDB 10.0 средствами параллельной репликации slave-серверов. В частности, обеспечена возможность параллельного применения к slave-серверу любых операций INSERT/UPDATE/DELETE, даже если они пока не завершены на master-сервере;
- Возможность проверки степени надёжности задаваемого пароля при помощи плагинов simple_password_check и cracklib_password_check;
- Внесена порция оптимизаций производительности, позволивших снизить нагрузку на CPU и увеличить эффективность работы на многоядерных системах. Тестирование показало прирост числа обрабатываемых транзакций от 135 до 190% и возможность обработки более миллиона OLTP-операций в секунду;
- Добавлены команды "EXPLAIN FORMAT=JSON" и "ANALYZE FORMAT=JSON", при которых вывод с оценкой характеристик запроса формируется в формате JSON. Штатный вывод команды ANALYZE теперь походит на вывод EXPLAIN, но включает полученные в результате выполнения запроса данные (число прочитанных строк и т.п.);
- Средства для пространственной привязки (Spatial Reference) данных геоинформационных систем. Реализация новых функций для работы с пространственными координатами: ST_Boundary, ST_ConvexHull, ST_IsRing, ST_PointOnSurface, ST_Relate;
- Поддержка выражений "IF EXISTS", "IF NOT EXISTS" и "OR REPLACE" в директивах "CREATE DATABASE", CREATE FUNCTION UDF", CREATE ROLE", CREATE SERVER", CREATE USER", CREATE VIEW", DROP ROLE", DROP USER", CREATE EVENT", "DROP EVENT" CREATE INDEX", "DROP INDEX" CREATE TRIGGER" и "DROP TRIGGER";
- Поддержка команд SHOW и FLUSH для плагинов, например, "SHOW LOCALES", "SHOW QUERY_RESPONSE_TIME", "FLUSH QUERY_RESPONSE_TIME";
- Поддержка директивы "SET DEFAULT ROLE", позволяющей определить роль по умолчанию, применяемую ко всем новым соединениям;
- Поддержка systemd.
И сейчас встал выбор СУБД для хранения основных данных. Начинал разработку на MySQL, но сейчас не уверен в выборе. Переезд на другую СУБД на данном этапе для меня не составит проблем (использую PDO). далек от ясного понимания что такое «высокие нагрузки» для СУБД. Просто по моим расчетам примерно через год база будет весьма увесистой (см. ниже)
Основной выбор стоит между MySQL, PostgreSQL, MariaDB. Также, возможен, но не приветствуется вариант Microsoft SQL Server на Windows Azure
Ситуация такова:
- Сложных запросов к базе нет. Максимум JOIN из двух таблиц
- Бо льшая часть запросов - чтение
- Есть одна самая важная и «главная» таблица (структура таблицы ниже под спойлером). Таблица будет расти примерно на 10-30 тысяч записей в сутки. Запись данных в эту таблицу - самое главное!
- Бо льшая часть запросов на чтение будет как раз к «главной» таблице. По этой таблице будет осуществляться поиск по любому из полей (в крайне редких случаях ~0.5% - по нескольким сразу). Поиск должен осуществляться быстро (не смотря на пункт №3)
- К «главной» таблице скорее всего будут добавлены индексы к каждому из полей сразу для двух полей (ownerID и Имя поля т.к. ownerID будет указан во всех запросах). Быстрый поиск будет нужен по любому из полей, но это не столь приоритетная задача. (Или лучше использовать Sphinx?)
- Львиная доля запросов (~80%) на чтение к «главной» таблице - простые select"ы по индексам from и personalID с limit = 20. Остальные запросы по любым другим полям по индексам (которых пока нет) ownerID и Имя поля, также с limit = 20
- Изменения данных в записях «главной» таблицы будут происходить крайне редко. Никакие записи из таблицы удаляться не будут.
- Поддержка транзакций и внешних ключей не обязательна
- Нужна возможность репликации данных типа master-slave
- Возможность шардинга на уровне СУБД приветствуется
- Крайне важна надежность БД (т.е. такой крах, как у MyISAM с ручным восстановлением сразу отпадает)
- К «главной» таблице могут добавляться новые поля. Это конечно крайне редкое явление и далеко не самое важное требование, но добавление нового столбца к таблице размером с десяток ГБ для MySQL весьма длительный процесс, а выносить новые поля в отдельную таблицу очень не хочется
- Всё это по-началу будет крутиться на таком вот выделенном сервере
- Другие таблицы будут расти медленно, и обращения к ним будут достаточно редкими, за них я не переживаю. Часто обновляемые данные у меня крутятся в redis"e
P.S. Желающих отправить меня гуглить прошу даже не отвечать. Найти информацию по сравнению актуальных версий разных СУБД мне не удалось, а изучать возможности, плюсы и минусы PostgreSQL, Microsoft SQL Server и MariaDB для человека, который с ними не работал весьма долгая задача. Да и в MySQL я далеко не эксперт, и подобный крупный проект для меня дело новое, да и возможности MySQL от версии к версии отличаются. Единственное, что я точно знаю, так это то, что таблицы типа MyISAM в MySQL мне точно не подойдут
- Вопрос задан более трёх лет назад
- 39797 просмотров