Маленькие поправки внесу для pom.xml: секция repositories не нужна, зависимости вытягиваются из апачевского репозитория; для ignite-spring и ignite-examples м.б. версия 1.4.0 (не уверен реально нужна ли зависимость на examples)?
Я бы сказал, что не MySQL стал менее популярен, а классические базы данных стали активно заменяться на NoSQL, in-memory key-value storage решения, там где возможности РСУБД не нужны (ну или получаются решения «из пушки по воробьям»).
Да? А мужики-то не знают. Оказывается, только благодаря деньгам оракл mysql на каждом хостинге оказалась. Не иначе и фейсбук подкуплен ораклом.
Ну так-то это правда, что после покупки Сана Ораклом у MySQL внутренние команды были существенно увеличены, причем девелопмента именно опенсорса. Стало существенно больше фокуса на качество. С другой стороны патчи, которые скажем приходили со стороны сообщества, я видел мало, хотя они были.
Собственно я бы еще добавил, что один из ведущих техлидов команды MySQL Replication Luís Soares в своем блогепостит описание новых фич (ну по ним можно примерно понять направление движения девелопмента), можно попробовать пообщаться с ним на темы физ. репликации и различных проблем.
О чем и речь. Комментарий о типах репликации я видел, в целом согласен. Хотя скажем в моем (ангажированном, конечно) понимании RBR более гибка, чем допустим вариант в постгресе (хотя я уже не имел возможности его глубоко потестить ). В RBR я могу на слейве иметь другую структуру таблиц: меньше полей (но с сохранением порядка следования), другие типы данных (по совместимые опять же). Отвязанность от storage engine дает возомжность менять (относительно, конечно) формат хранения страниц в движке не ломая совместимость в режимах old master — new slave.
Да еще никто не упомянул GTID, которые позволяют иметь фактически любую топологию, менять ее и гарантировать что а) данные на серверах будут up-to-date, б) никакой апдейт не применится более одного раза на сервере.
По последнему пункту — Оракл расширил команду MySQL, но приоритет отдается стабильности, поэтому форки имеют возможность дать больше фич раньше оригинального продукта.
Так-то RBR репликация в MySQL как раз «тру бинарная». Другой вопрос, что не всем она подходит и стейтмент репликация может эффективнне с точки зрения нагрузки на сеть, размеры бинлогов и т.д.
Точнее будет, что в 5.6 появилось много нового функционала и MariaDB нужно потратить ресурсы на бэкпортинг и совместимость фич MariaDB 10 и 5.6. Это проблема всех форков: поддерживать совместимость с родительским продуктом пока не наберется достаточная инсталляционная база, чтобы позволить что-то не поддерживать.
XtraDB это оригинальный InnoDB с внешними патчами (своими и сторонними) и поддерживается Перконой, а не MariaDB. С учетом, что InnoDB до сих пор разрабатывается и поддерживается Ораклом это не совсем одно и тоже. И не факт, что код/фичи innoDB не начнут конфликтовать со сторонними патчами XtraDВ. Ситуация аналогична выходу MySQL 5.6, но все форки живут все еще на 5.5 (продакшн). и активно бэкпортят фичи с 5.6.
Так что формально innodb в MariaDB можно подключить лишь как плагин, а это не тоже самое, что built-in.
Сравнивать действительно можно что угодно, но в данном случае имеет смысл сравнивать стабильность/производительность/фичи/баги/поддержку. Общие слова, что «оракл -плохой, форки — хорошие» как минимум неконструктивны.
В данном случае я имел в виду storage engines и сам неглубоко в теме, что именно сделано в MariaDB, но вот сейчас открыл их сайт и вижу, что
— innodb нет в списке поддерживаемых storage engine для MariaDB
— aria не транзакционный storage engine
Тут так совпало что как раз пришел ролик от Синтакор, вполне интересно в рамках текущих дискуссий здесь про процессоры и пути развития:
https://www.youtube.com/watch?v=DpfxbqUl0ko&list=PLeTROrEGesW6kLeQ_64KV_L1w44Vfp_ee
Ну так-то это правда, что после покупки Сана Ораклом у MySQL внутренние команды были существенно увеличены, причем девелопмента именно опенсорса. Стало существенно больше фокуса на качество. С другой стороны патчи, которые скажем приходили со стороны сообщества, я видел мало, хотя они были.
p.s. я коллега kaamos, ушел правда позднее
Да еще никто не упомянул GTID, которые позволяют иметь фактически любую топологию, менять ее и гарантировать что а) данные на серверах будут up-to-date, б) никакой апдейт не применится более одного раза на сервере.
Так что формально innodb в MariaDB можно подключить лишь как плагин, а это не тоже самое, что built-in.
Сравнивать действительно можно что угодно, но в данном случае имеет смысл сравнивать стабильность/производительность/фичи/баги/поддержку. Общие слова, что «оракл -плохой, форки — хорошие» как минимум неконструктивны.
— innodb нет в списке поддерживаемых storage engine для MariaDB
— aria не транзакционный storage engine
Т.о. имеет смысл сравнивать только сравнимое?