В находящейся в разработке ветке CУБД MySQL 8.0 (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/) (версия 8.0 будет выпущена следом за 5.7, вместо 5.8) представлены
изменения (https://www.percona.com/blog/2016/10/11/mysql-8-0-end-myisam/), ограничивающие использование хранилища MyISAM. Поддержка MyISAM пока сохраняется, но использование данного хранилища в самом MySQL практически прекращено. В частности, после реализации в MySQL 8.0 нового механизма (https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html) хранения системных данных, таблицы MyISAM больше не используются для хранения системной схемы (БД mysql) и теперь невозможно просто скопировать таблицы MyISAM на работающий сервер MySQL (скопированные таблицы не будут определены, в отличие от таблиц InnoDB, для которых можно выполнить "ALTER TABLE … IMPORT TABLESPACE"). Возможность создания таблиц с опцией "engine=MyISAM" сохранена.
Ранее хранилище MyISAM предоставляло поддержку ряда возможностей, отсутствующих в InnoDB, но в ветках MySQL 5.6 и 5.7 функциональность была выровнена и в InnoDB появились такие функции как полнотекстовые индексы, табличные пространства, пространственные индексы (RTREE), отслеживание последнего обновления, пригодность для временных таблиц и ускорение работы функции "count(*)". До сих пор оплотом MyISAM было использование данного хранилища для системных таблиц, но в MySQL 8.0 системное хранилище было переведено с MyISAM. Таким образом, не осталось препятствий для воплощение в жизнь
предложения (http://bugs.mysql.com/bug.php?id=78553) по переводу MyISAM в разряд опциональных хранилищ, подключаемых при необходимости в форме плагина. Из достоинств MyISAM остаётся более компактное хранение данных на диске в несжатом виде и значительный выигрыш в производительности выполнения операции count(*).URL: https://www.percona.com/blog/2016/10/11/mysql-8-0-end-myisam/
Новость: http://www.opennet.dev/opennews/art.shtml?num=45315
Увы, еще одна удобная фишка есть только в MyISAM - MRG_MyISAM.
MRG_InnoDB?Просто добавить View
Единственная там удобная фишка -- это дефрагментация.
> Единственная там удобная фишка -- это дефрагментация.В InnoDB тоже фейсбук добавил дефрагментацию :P
>отмечается закатХм. Мерзко звучит. Может "происходит отказ от" или что-то в этом роде?
>выровненаМожет всё-таки "выравнена" от слова "равенство", а не "выровнена" от слова "ровно"?
http://gramota.ru/slovari/dic/?word=%D0%B2%D1...
клоун: это называется "чередование". Весьма распространённое (и жутко неудобное для изучающих русский язык иностранцев) явление.http://licey.net/free/4-russkii_yazyk/39-kurs_russkogo_yazyk...
Все слова являются исключениями. Правила есть, но они работают 50:50. Так, если после корня стоит "т" и ещё какие-нибудь буквы, то "о" часто меняется на "а": рост - росли - расти - растить, но мост - мостить.
...
По сути он прав, слово "закат" в данном контексте употреблено неверно. Правильнее было бы употребить "отказ".
Закатывают вручную просто.
Как будто, MySQL какая то секта, а MyISAM важная эпоха... а по сути так и есть. :)
Отказ от myisam для системных словарей - это действительно прямо ВЕХА. И там настолько это было гвоздями прибито в коде, что работа проделана просто огромная.Неверсионность DDL всегда создавала кучу проблем и была одним из ключевых недостатков mysql.
Использование MySQL вместо MariaDB оправдано на данный момент или это синдром утёнка?
Нет ни малейшей причины не использовать MariaDB.
Какая вообще разница? Примерно как между Chrome и Chromium?
> Нет ни малейшей причины не использовать MariaDB.Atlassian Status as of 28 April 2015
Hello All,
Given our current product priorities and other high ranking JAC issues we do not have plans to add MariaDB support in the foreseeable future.
If anyone has DB vendor/type marketshare information - I'd love to see it to make an assessment of whether to add this to our supported platforms.
When choosing to add a supported platform we assess the expected benefit of minimising the number of supported platforms vs. the level of tech debt that reduces our development velocity.Thanks for your feedback and we hope you appreciate our open approach to these requests.
Danke schoen,
Otto Ruettinger
JIRA Principal Product Manager
У нас Confluence на MariaDB Galera работает. С Galera есть свои тонкости, а вот если без галёры - полный drop-in replacement без особых проблем.
нет никаких причин переходить на MariaDB - учитывая страсть автора к странным лицензиям и перепродаже воздуха.
> нет никаких причин переходить на MariaDB - учитывая страсть автора к странным
> лицензиям и перепродаже воздуха.А у Оракла страсть к странному развитию продукта, которое со стороны может показаться закапыванием. У всего есть плюсы и минусы.
(Сразу скажу, что моё мнение основано на чтение блогов, людей, причастных к.)Выглядит так, что MariaDB к сожалению постепенно отходит от MySQL в совсем уж самостоятельный форк. Другими словами, эти две системы быстро отходят друг от друга по фичам, и через некоторое время (если уже не) MariaDB перестанет быть тем самым "drop-in replacement" для MySQL, а это сильно сУзит область её применения.
То есть мне, например, сильно импонирует то, что MariaDB разрабатывается существенно более открыто (MySQL разрабатывается методом перекидывания релизов через забор; багтрекер закрыт для пользователей без support-контракта с Ораклом), но для большнства людей MySQL это именно MySQL, а не MariaDB, а значит вполне можно ожидать что скоро какой-нибудь там Астериск или, там, очередная CMS или CRM с MariaDB *вместо* MySQL уже не заработает.
Если же Вы выбираете RDBMS под свои собственные нужды (под свою разработку), то нет смысла задавать вопрос, который Вы задаёте: вместо этого изучите наборы фич каждой реализации в версиях под вашу целевую ОС, сравните производительность тестами. Заодно и на постгрес посмотрите, например.
> MariaDB к сожалению постепенно отходит от MySQL в совсем уж самостоятельный форкНу и о чём тут сожалеть?
*Шутка про погоню за версиями, чтобы догнать и перегнать Chrome*
Chrome уже выполнил главный квест прикладного ПО — превращение в операционную систему. Его не догнать.
> версия 8.0 будет выпущена следом за 5.7, вместо 5.8Это запоздалый и кривой бекпорт из MariaDB, или это вирус Хрома начал поражать вэб-технологии?
У PHP была объективная причина, пропустить 6-ую версию, и по случайности совпало, что вместо 5.7 вышла 7.0.
MariaDB, хотела чтобы считали, что у ней писька длиннее, чем у PostrgeSQL.
Но какой смысл мускулу переходить на 8-ую версию?
У MariaDB писька коротка, но еще перерастет таковую у PostrgeSQL.
Радует что не перевелись еще такие как ты.
Самый умный парень на все село?
Много фундаментальных изменений -> необходима смена мажорной версии. 6 версию пропустили т.к. была. 7 версию перескочили т.к. нынче трендово.
http://semver.org/ и будет всем счастье. Не надо ничего придумывать.
> Много фундаментальных изменений -> необходима смена мажорной версии. 6 версию пропустили
> т.к. была. 7 версию перескочили т.к. нынче трендово.6-ой версии ни в релизе, ни в учебниках не было.
В 5.5 то же много чего фундаментального поменяли, но на 6 не перескакивали.
И с каких это пор цифра 7 перестала быть трендовой?
6.0 версия была, но была заморожена еще на стадии альфа-тестирования
> 6.0 версия была, но была заморожена еще на стадии альфа-тестированияНу мало ли, что было несколько лет назад в планах у разработчиков.
Насколько я понял, эта версия выщла как 5.5.
В PHP была схожая ситуация, но её успели много кто потестировать, её много кто ожидал, не меньше чем Perl 6, изменения там были колоссальные, и вышла она как 5.4, но главное, информация про её скорый релиз, и частичную функциональность, утекла во множество учебников. А тут лишь в Вики можно прочитать, что оказывается давным-давно, в далёкой-далёкой галактике...
Причина пропуска никак не объективная.
Имелось ввиду не 7 перескакивать трендово, а трендово скакать вообще. Чем они хуже мелкософта?
клоун: у Майкрософта то как раз всё... сложно :)."Windows 10" - это маркетинговое название, не имеющее никакого отношения к внутренней нумерации, также как и "Windows 7".
Функция GetVersionEx возвращает 6.2 для W8 и 6.3 для W8 (с обновлениями) и W10, что тонко намекает на количество изменений.
Чтобы определить, что это именно W10 необходимо вызвать новую функцию - IsWindows10OrGreater(), а старые (GetVersion, GetVersionEx) считаются устаревшими и не должны больше вызываться.
Неужели ты думаешь, что кому-то, кроме того мелкого сотрудника M$, который направил тебя на этот сайт, интересно, что там возвращают кривые функции в замороченном поделии индусов-извращенцев из M$?
клоун: мелкого... Хех. Видел бы ты какой у него мелкий...
Здесь утверждается что была: https://ru.wikipedia.org/wiki/MySQL#MySQL_6.0
Ну что за позерство?
По-моему логичная смена нумерации. Раньше были 5.6, 5.7, которые вроде как выглядят минорными, но такими не являются. Изменений в новой достаточно.
Версию к тому же приравнивают к MySQL Cluster.
В итоге всем удобно, а Вы рассуждайте и дальше про длину кхе-кхе.
> По-моему логичная смена нумерации.
Для людей не хотящих думать, а занимающихся популизмом - да.
Ну таково мнение Оракла, а Вы с воплями "как же так можно нумеровать" действительно можете идти куда подальше. Нормальных людей не очень цифры версии волнуют.
> Версию к тому же приравнивают к MySQL ClusterА это и есть реальная причина.
PS: а свои "смишные" картинки оставьте, пожалуйста, для других ресурсов, если нечего сказать.
Всё просто. Проект завис на версии 5. Вот они 5 отбросили, и сделали минорную циферь мажорной. Всё вполне логично. Ничего не перескакивали.
Поддерживаю, это первое, о чём я подумал, когда увидел 5.5 → 5.6 → (5.)7
ой, не застали вы slackware 7.0 задолго до хрома. там к нему в комлекте шло чудесное описание, почему была версия 4.0, а стала 7.0
или solaris 7 после 2.6 незадолго до слаквари
После (2.)6 идёт 7, потому что в (2.) больше нет необходимости, всё правильно.
Не застал. Мне, к сожалению, в моё время примеров хватает, даже через чур.
InnoDB с ее жором памяти тоже пора закатывать и убирать в дальний угол кладовки.
> InnoDB с ее жором памяти тоже пора закатывать и убирать в дальний угол кладовки.Те кто так считают, уже давно перелезли на PostgreSQL, а то и изначально используют его.
> давно перелезли на PostgreSQL, а то и
> изначально используют его.Зачем Вы разрушаете уютный мир выпускников трёхмесячных курсов веб-дизайна? MySQL - их первая любовь на всю жизнь.
MySQL - моя первая любовь. И серьезно разобравшись в вопросе я понял, под мой круг задач MySQL оптимальнее. И я вообще не понимаю тот фанатизм, который развернулся вокруг PostgreSQL. На мой взгляд все эти люди просто некомпетентны в вопросе, повелись на мишуру.
Mysql тупо быстрее, предсказуемее (потому что блокировочник), проще в обслуживании и примитивнее в использовании. Для веба в самый раз.
> Mysql тупо быстрее, предсказуемее
> потому что блокировочникАга, разобрался он в вопросе. Видишь, мускулем пользуются только одни идиоты не способные хоть немного понять как работает ПО которым они пользуются.
И еще плохой планировщик запросов.
> предсказуемееНу, с MyISAM точно нет, т.к. нет нормальной транзакционности.
Имхо, лучше сказать, что вы её лучше изучили. Но это не является объективным плюсом именно mysql.
к сожалению есть масса легаси кода, и крупных проектов где просто так БД не сменишь. так что mysql нужно по возможности тоже допиливать.
С этим я не спорю. Я говорю за новые проекты и за те, которые не слишком завязаны на InnoDB или прочие движки.
Так только позеры считают и религиозные фанатики.
Нормальному человеку понятно, что MySQL и PostgreSQL - это ну очень разные инструменты. И в зависимости от поставленной задачи и конкретных условий всё сильно меняется, поэтому ответа на вопрос "Что лучше MySQL или PostgreSQL?" - нет.
>> MySQL и PostgreSQL - это ну очень разные инструментыможно подробнее? (реально интересно, это не троллинг)
Не знаю что имел ввиду iPony, для меня решающая разница - поддержка движков таблиц. Под каждую задачу я могу выбрать таблицу с оптимальной для нее структурой хранения данных. Под специфические задачи я могу написать свой табличный движок. В версии 8.0 добавят найтивное партицирование, можно будет формировать гибридные таблицы. В PostgresSQL такого никогда не будет. Зато они не тратя время на поддержку движков действительно здорово продвинулись в других вещах, без которых, впрочем, можно обойтись.
> без которых, впрочем, можно обойтись.Это субъективное мнение.
Я вот думаю, что при наличии приемлемого встроенного движка, без поддержки сторонних движков вполне можно обойтись.
Разница между MVCC движками и тем что в MyISAM огромна, другое дело что в MySQL почему-то его решили грохнуть.
Посмотри код myisam - и вопрос отпадёт сам собой. Он чудовищно написан, а джедаев на его поддержку как-то не находится.
По факту почти везде innodb. memory какой-то тормознутый (лок на уровне таблицы при insert, например, чего стоит), archive ненадежный (лично приходилось несколько раз восстанавливать).
>найтивноекакая сложная рушшиан лангуага.
>сложная рушшиан лангуага.Лангважа!
> Под специфические задачи я могу написать свой табличный движок.Это всё полнейшая чушь, не можешь.
Во-первых, все прользователи мускуля тупые овощи и они едва осилят нагогнокодить даже myisam подобную хрень.
А во-вторых, фичи мускуля-подобной СУБД в мускуле поддерживает только один движок и это innodb. Остальные же сторадж плагины создают большую головную боль разработчикам т.к. они умеют небольшое подмножество фич и пользователи постоянно наступают на грабли неоднородности функционала. Например, для многих оказывается неожиданностью, что myisam не держит rw нагрузку и ложит сервер.
Реализовать близкий по функционалу и качеству движок не под силу кучше школоло, а у профессионалов уходят годы чтобы просто сделать творческое производное от этого же innodb. Потому в нормальных СУБД есть примерно один тесно интегрированный движок который пилят годами.
И даже до овощей из мускуля наконец таки доходит, что движок должен быть один и лучше допиливать фичи в этот один сторажд, чем пытаться поддерживать кучу неоднородных плагинов.
>В PostgresSQL такого никогда не будет.Отвечаешь?
Вообще у разработчиков давно в планах поддержка взаимозаменяемых движков, сейчас производителям проприетарных дб на базе постгресса приходиться форкать весь постргес, что мешает им контрибьютить изменения обратно.
MySQL очень гибкая. Назовите любую задачу и на MySQL её можно решить значительно эффективнее, чем на PostgreSQL. Главное чтобы руки из нужного места росли, чем не славятся фанатики PostgreSQL.
> MySQL очень гибкая. Назовите любую задачу и на MySQL её можно решить
> значительно эффективнее, чем на PostgreSQL. Главное чтобы руки из нужного места
> росли, чем не славятся фанатики PostgreSQL.Триггеры?
В 5.7 всё стало нормально. Почти не осталось непонятных ожиданий "пока кто-то схему отпустит" и прочих "левых" блокировок, которые возникали потому что из after триггера запускали обновление другой таблицы, которая в это время была занята (да и ещё MyISAM-овская). Поэтому и ставили задержку в 10-15 секунд на заброс - такая блокировка сама отваливалась через таймаут. Сейчас этого нет, InnoDB почти повзрослел и покрывает большую часть функций "тупо хранить в табличке и не терять связей". Ну да, наследования таблиц и структур нет и не будет, но задач, когда необходимо один набор данных расширять у современных разработчиков почти нет.
> В 5.7 всё стало нормально. Почти не осталось непонятных ожиданий "пока кто-то
> схему отпустит" и прочих "левых" блокировок, которые возникали потому что из
> after триггера запускали обновление другой таблицы, которая в это время была
> занята (да и ещё MyISAM-овская). Поэтому и ставили задержку в 10-15
> секунд на заброс - такая блокировка сама отваливалась через таймаут. Сейчас
> этого нет, InnoDB почти повзрослел и покрывает большую часть функций "тупо
> хранить в табличке и не терять связей". Ну да, наследования таблиц
> и структур нет и не будет, но задач, когда необходимо один
> набор данных расширять у современных разработчиков почти нет.Be aware of that MySQL does foreign key checks BEFORE invoking any trigger. So it is not possible to implement a BEFORE INSERT trigger that enters up a missing column value with a foreign key constraint.
https://jira.mariadb.org/browse/MDEV-8605NOT NULL constraint must be checked *after* the BEFORE triggers.
That is for INSERT and UPDATE statements even NOT NULL fields
must be able to store a NULL temporarily at least while
BEFORE INSERT/UPDATE triggers are running.
Реализовать встроенные пакеты на PL/SQL ?
> MySQL очень гибкая. Назовите любую задачу и на MySQL её можно решить
> значительно эффективнее, чем на PostgreSQL. Главное чтобы руки из нужного места
> росли, чем не славятся фанатики PostgreSQL.Ну, например, физическая репликация транзакционного движка.
Да пожалуйста, сколько угодно1. Кастомные типы данных, скалярные и комплексные вроде json, xml, intarray, hstore. Инфраструктура для кастомных типов, это обобщённые индексы GIN, GiST, SP-GiST. Пусть хотя бы будет тип для хранения IP адресов и их индексирования.
2. Как развитие предыдущего пункта, PostGIS (расширение для создания ГИС).
3. Нормальные хранимки на каких угодно ЯП.
4. Возможность асинхронно пользоваться СУБД стоковым клиентом.
5. Возможности оптимизации движка, планировщика и т.д.
6. Репликации. Сейчас их в PG столько разных с разными фичами, что мускуль отстал в этом вопросе на несколько поколений развития СУБД.
7. Традиционный функционал для реляционных СУБД, это ссылочная целостность (FOREIGN KEY). В мускуле она не всегда нормально работает даже c innodb. А все остальные плагины её просто не умеют.
8. Аналитические функции и вообще уровень поддержки стандартного SQL. Сюда можно вообще засунуть все задачи с аналитикой, это в частности и обработка сложных запросов, построение эффективных планов выполнения для них.
Каждый пункт выше можно превратить во множество практических задач в которых mysql позорно сливает.
Справедливости ради:> 5. Возможности оптимизации движка, планировщика и т.д.
С этим уже неплохо в последних версиях Марии (в 8-ке, говорят, тоже).
Там уже комбинированный rule-based + cost-based оптимизатор.> 7. Традиционный функционал для реляционных СУБД, это ссылочная целостность (FOREIGN KEY).
> В мускуле она не всегда нормально работает даже c innodb.Нормально там все в innodb, если специально (или по отсутствию ума) не использовать средства для отстреливания себе ног, предназначенные для особых случаев.
По остальным пунктам согласен.
> Назовите любую задачуЭффективный поиск по разреженному набору атрибутов в различных комбинациях (скажем, есть 500 возможных атрибутов, из которых 450 обычно null). Вот как в яндекс-маркете.
В postgresql есть gin и gist-индексы, hstore и jsonb. Что предлагает тут mysql?
На, просвещайся: https://dev.mysql.com/doc/refman/5.7/en/json.htmlА вообще в таких случаях берут монгу, а не sql.
дебил, монга не ACID СУБД.
Дeбил, для витрины магазина и не нужна ACID.
Дебил, что нужно определяет архитектор.
Ну и если даже отойди от ACID, то монга ещё умудряется и сливать в производительности PG.
> На, просвещайся: https://dev.mysql.com/doc/refman/5.7/en/json.htmlИ где там inverted index?
> А вообще в таких случаях берут монгу, а не sql.
И где в монге inverted index?
"Мама, сматли, я знаю про inverted index!!11"Т.е. с наличием json в mysql ты обоcpался и тут же стал требовать что-то другое. Ну покажи мне в посгре map-reduce тогда.
Я прекрасно знаю, что в mysql есть json.
Что я требую, написано в том комментарии. json для этой задачи нафиг не нужен, постгресовская комбинация jsonb+gin приведена как пример решения задачи. Задача - эффективный поиск.
Теперь открой непосредственно маркет, посмотри на его сайдбар с чекбоксами, прикинь операции, потребные для выборок и скажи что из этого не умеет монга.Я прямо сказал, что реляционная база тут наxeр не нужна, потому что структура данных для неё не подходит - будет или большущая sparse-table, или куча мелких с километровыми join'ами, с хаками в виде частичной денормализации и триггерами для разруливания её последствий.
А использование GIN в данном случае - это корявый костыль для утят, не желающих бросать любимую реляционную цацку, вместо того чтобы её выкинуть целиком и взять инструмент по задаче.
Да, молодцы, научились микроскопом колоть орехи. Теперь осталось понять наxepа вы это сделали.
Прикинул операции. В монге будет fullscan. В постгресе будет gin index lookup.Gin - это реализация инвертированного индекса. Реляционка или нет - не важно, можно взять Solr и в нем будет работать точно так же. А в монге будет фуллскан.
> В монге будет fullscanПовторяй почаще, авось сам поверишь.
http://blog.mongodb.org/post/59757486344/faceted-search-with...
И, да, в монге нет эффективного поиска для данной задачи, там btree, что вообще для документной базы решение странное.Я бы еще понял, если бы был упомянут Solr - вот там действительно все есть, что надо.
Те кто так считают, уже давно используют TokuDB. PostgreSQL в этом смысле не лучше, не надо тут навязывать неправильные решения, если не разбираетесь в сути дела.
> Те кто так считают, уже давно используют TokuDB.Про неё я слышу впервые. Попытка на офф сайте почитать документацию, приводи к запросу указания моих данных, чего мне не особо-то и хочется. https://learn.percona.com/download-percona-tokudb-7-5-manual
В SHOW ENGINES в 10-ой Марии её, естественно, нет.
Поведайте же нам, что это вообще такое?
>> Те кто так считают, уже давно используют TokuDB.
> Про неё я слышу впервые. Попытка на офф сайте почитать документацию, приводи
> к запросу указания моих данных, чего мне не особо-то и хочется.
> https://learn.percona.com/download-percona-tokudb-7-5-manual
> В SHOW ENGINES в 10-ой Марии её, естественно, нет.
> Поведайте же нам, что это вообще такое?
>> Те кто так считают, уже давно используют TokuDB.
> Про неё я слышу впервые. Попытка на офф сайте почитать документацию, приводи
> к запросу указания моих данных, чего мне не особо-то и хочется.
> https://learn.percona.com/download-percona-tokudb-7-5-manual
> В SHOW ENGINES в 10-ой Марии её, естественно, нет.
> Поведайте же нам, что это вообще такое?https://mariadb.com/kb/en/mariadb/enabling-tokudb/#check-for...
/etc/my.cnf.d/tokudb.cnf -> uncomment mariadb
https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb...
>> Те кто так считают, уже давно используют TokuDB.
> Про неё я слышу впервые. Попытка на офф сайте почитать документацию, приводи
> к запросу указания моих данных, чего мне не особо-то и хочется.
> https://learn.percona.com/download-percona-tokudb-7-5-manual
> В SHOW ENGINES в 10-ой Марии её, естественно, нет.
> Поведайте же нам, что это вообще такое?http://www.opennet.dev/opennews/art.shtml?num=36779
Вообще, очень странный движок, но имеет свою нишу.
Честно, скажите, что есть действительно необходимого в PostgreSQL, чего нет в MySQL?
оптимизатор нормальный?)
Оптимизатор в MySQL хорош, будем спорить?
> Оптимизатор в MySQL хорош, будем спорить?В MariaDB больше флагов.
Да
Выкатывайте примеры, которые вам каждый день жить не дают, посмотрим. Я лично сталкивался с проблемами оптимизатора за 8 лет работы с MySQL только 1 раз.
> Выкатывайте примеры, которые вам каждый день жить не дают, посмотрим. Я лично
> сталкивался с проблемами оптимизатора за 8 лет работы с MySQL только
> 1 раз.Везет.
Никогда не писали use/force index, STRAIGHT_JOIN и хаки типа where updated_at = updated_at?
Завидую прямо.
>> where updated_at = updated_at?а можно подробнее? чувствую пригодится)
Если не страдаете археологией, не пригодится. :)
В последний раз использовал такой трюк для выбора более эффективного индекса в версии 4.1.
Да вы батенька Пхпист
Я много чего -ист. :)
А вас это беспокоит? Хотите об этом поговорить?
http://sqlinfo.ru/forum/viewtopic.php?pid=43892
это из того что недавно пришлось ковырять.
> http://sqlinfo.ru/forum/viewtopic.php?pid=43892
> это из того что недавно пришлось ковырять.Если со времён 5.0 ничего не изменилось, то дело тут в ORDER BY. LIMIT с 2-мя параметрами для ограничения перебора таблицы, есть смысл использовать только если отсутствует сортировка. А если есть сортировка, то запрос всё равно будет перебирать всю таблицу, что бы отсортировать.
>> А если есть сортировка, то запрос всё равно будет перебирать всю таблицу, что бы отсортировать.нет, это не так, если попадаем в индекс с сортировкой, то все будет хорошо.
в моем примере скорее всего проблема в том, что полностью индекс из-за OR использовать не удается.
> Честно, скажите, что есть действительно необходимого в PostgreSQL, чего нет в MySQL?Физическая репликация.
Более оптимальное распределение памяти.
PL/pgSQL
UPSERT (В MySQL REPLACE не то, а у INSERT ... UPDATE ... корявый и избыточный синтаксис)
тригонометрические ф-ииИ это только то, что читал беглым взглядом.
P.S. Я не хейтер Постреса, я сам сейчас работаю с Марией, но уже задумываюсь о дальнейшем переходе на Пострес, и мне важно именно объективное мнение достоинств и недостатков обоих, хотя и к субъективным мнением прислушиваюсь.
> Физическая репликацияКоторая сocёт на разнесённых репликах. Ширину канала можно добавить, а вот RTT не нaе6ёшь.
> PL/pgSQL
> тригонометрические ф-ииДа это бывает удобно. Однако пихать логику в базу - общепризнанная bad practice, убивает на корню горизонтальную масштабируемость.
> UPSERT
Который добавили только в 9.5 и который является аналогом ON DUPLICATE KEY, существующим уже тыщщу лет как.
> Более оптимальное распределение памяти.
Угу, особенно с её-то моделью "по процессу на коннект". А боунсер - это сторонний костыль.
>> UPSERT
> Который добавили только в 9.5 и который является аналогом ON DUPLICATE KEY,
> существующим уже тыщщу лет как.не совсем
> Да это бывает удобно. Однако пихать логику в базу - общепризнанная bad
> practice,Смотря какую логику.
Бывает логика хранения или валидации данных, которую не выразить простыми constraints, или умышленная денормализация для производительности. И тут триггеры абсолютно уместны.> убивает на корню горизонтальную масштабируемость.
И каким же образом? Абсолютно перпендикулярные вещи.
> которую не выразить простыми constraintsНу приведите пример, что ли. Триггеры - это как раз то, с чего всё начинается. Примерно та же ситуация, что с плюсовыми шаблонами.
> И каким же образом?
А таким, что как только мастер упирается в лимит железа или времени выполнения, то мы оказываемся в жoпе. Мастер-мастер для RDBMS работает или с кучей оговорок или не работает вовсе, а на слейв ты писать не можешь.
> Ну приведите пример, что лиhttp://guides.rubyonrails.org/association_basics.html#polymo...
> мастер упирается
А почему без хранимок-триггеров мастер не упрется?
Упрётся, но позже, поскольку база меньше нагружена. Это позволяет нацеплять к ней больше инстансов приложения и разнести их по разным хостам.И наоборот, при запихивании всего по максимуму в базу - будешь ограничен производительностью одной железки, где крутится база.
>> Физическая репликация
> Которая сocёт на разнесённых репликах. Ширину канала можно добавить, а вот RTT
> не нaе6ёшь.Интересно про RTT. Чем она мешает? В postgres просто передаются wal файлы. Как вы это настроите, так они и будут передаваться. Если они забираются медленно, нужно просто подкрутить настройки, чтобы мастер их не удалил раньше.
Кроме того, теперь есть replication slots https://habrahabr.ru/post/245847/
Грубо говоря, сервер будет держать wal файлы до тех пор, пока их не заберет последняя реплика.
Популярно про RTT: https://habrahabr.ru/company/ibm/blog/274807/Популярно про механизмы репликации в mysql/pgsql: https://habrahabr.ru/post/269889/
Учитывая, что в посгресе наблюдается явный перекос в сторону физической репликации, выводы сделаешь сам.
> Популярно про RTT: https://habrahabr.ru/company/ibm/blog/274807/На графике при задержке 100мс скорость падает с 1Гб/с до 100Мб/с.
Если бы это было так, это было бы везде, а не только на слайдах.
Такое было возможно в ОС Windows где-то до Windows Vista изза использования устаревших алгоритмов борьбы с перегрузкой. Или в современных ОС с кривыми настройками.
Я спокойно качаю и на больших скоростях с такой задержкой, так что для меня налицо подтасовка фактов.По хорошему, статью можно закрыть после вот этого:
>Протокол FASP работает на базе протокола UDP (User Datagram Protocol)Ещё одни "изобретатели" TCP на базе UDP.
> Популярно про механизмы репликации в mysql/pgsql: https://habrahabr.ru/post/269889/
Да, но в mysql репликация так же по TCP, которая подчиняется тем же "проблемам".
Так что могу сделать вывод, что вам просто хотелось высказать что-то умное.
> Более оптимальное распределение памяти.Берем TokuDB, включаем сжатие и смотрим на сколько экономнее расходуется дисковое пространство. На моих задачах сжатие достигает 5 раз.
Берем MEMORY, кладем в нее скоропортящиеся данные телеметрии. Табличка в 1 гиг летает, Postgresql же просто убъет ssd непрерывной перезаписью.
Берем табличку Archive с полнотабличным сжатием и кидаем в нее все логи. Сжатие при этом достигает 20 и более раз.
Как реализовать таблицу для работы с манчестером или сетевым устройством под MySQL я знаю, а в Postgresql это в принципе не возможно В ней просто ничего не заложено для организации работы с другими устройствами. Postgresql сейчас даже не способна работать с оперативкой без костылей..., о каком распределении может идти речь?
И это всё не включая возможностей версии 8.0, которая позволит создавать гибридные таблицы с любым распределением данных по любым устройствам памяти.
> UPSERT (В MySQL REPLACE не то, а у INSERT ... UPDATE ... корявый и избыточный синтаксис)UPSERT думаю добавят. Но это не то, без чего нельзя прожить
> тригонометрические ф-ииТригонометрические ф-ии в базе я не использую, и мне даже сложно представить зачем они там и для каких задач их наличие там может пригодиться.
Знатно вы вкатали постгерам,
В mysql мелкие проблемы решаются по мере поступления.
В pgsql для решения проблем нужно привлекать инженеров/архитекторов и кучу дополнительных костылей по бокам.
Справедливости ради, не вижу особого вката.
Для скоропортящихся данных есть redis, хранить логи в DB... , не знаю, может и есть смысл в этом, но я не могу сходу придумать зачем их нужно там хранить, как и любые данные, специфичные для движка Archive.
TokuDB по умолчания в MariaDB нет, и её ещё нужно установить, возможно скомпилировать, а то и перекомпилировать и сервер, и настроить. Чем не костыль?
На говнохостингах на Сентосе это точно не вариант.
MaxScale[CreateTableFilter]
type=filter
module=regexfilter
options=ignorecase
match=TYPE\s*=
replace=ENGINE=Заменить ENGINE на ходу регуляркой в MySQL прокси.
Переключить таблицы по умолчанию на TokuDBДвижки MyISAM отключить и переключить на использование Aria с ROW_FOMAT=PAGE для временных таблиц;
InnoDB отключить.
Используем для массового хостинга свяку mysql прокси 3306 за ней mysql
В MySQL я одним запросом перегоняю нужные данные из оперативки в любую таблицу, попутно обрабатывая их. На связке redis + posgresql такого не сделать.
Про TokuDB неправда. В MariaDB 10.0/10.1 идёт "из коробки".
Убедили, поэкспериментирую с TokuDB.
Вы так говорите, будто в постгресе сжатие использовать вам кто-то мешает. Намного проще, причем, чем какие-либо сторонние TokuDB (неизвестно с какими особенностями).# zfs get all pgsql/data
NAME PROPERTY VALUE SOURCE
pgsql/data type filesystem -
pgsql/data creation Пт сен 2 19:20 2016 -
pgsql/data used 837G -
pgsql/data available 603G -
pgsql/data referenced 836G -
pgsql/data compressratio 2.49x -
...
pgsql/data recordsize 32K inherited from pgsql
pgsql/data mountpoint /var/lib/pgsql/9.5/data local
pgsql/data sharenfs off default
pgsql/data checksum on default
pgsql/data compression lz4 inherited from pgsql
...
pgsql/data logicalused 2,03T -
Откройте для себя TokuDB и удивитесь.
XtraDB !== InnoDB
К сожалению, в этом смысле разницы нет. В обоих движках постраничная организация памяти, приводящая к большим накладным расходам памяти и, фактически, к невозможности эффективно всё это сжимать. TokuDB станет заменой XtraDB и MyISAM.
там же куча движков
infinidb
Brighthouse
KFDB
ScaleDB
Spider
PBXT
> там же куча движков
> infinidb
> Brighthouse
> KFDB
> ScaleDB
> Spider
> PBXTИ как подключить хоть один из них?
Tokudb: https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb...
Плюс получите очень эффективное сжатие, и большую скорость, чем даже у Postgresql. И SSD проживет дольше, чем под Postgresql, если такая связка используется.
> Tokudb: https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb...
> Плюс получите очень эффективное сжатие, и большую скорость, чем даже у Postgresql.
> И SSD проживет дольше, чем под Postgresql, если такая связка используется.Внешние ключи не умеет, скоро 2017 год.
> Внешние ключи не умеет, скоро 2017 год.FOREIGN KEY? От него и в InnoDB толку чуть меньше чем нуль.
Вот это откровение. Целостность? Не не слышал
>> FOREIGN KEY? От него и в InnoDB толку чуть меньше чем нуль.
> Вот это откровение. Целостность? Не не слышалБеру свои слова назад. Только что проверил - работает.
Когда лет 5 назад пробовал, он у меня не работал.
Внешние ключи, партицирование и многое другое обещают вынести из обязанностей таблиц в обязанности самой бд в 8 версии
Партиционирование выкинули из MySQL 8.0 я развею ваши потные мечты.
Да ну? https://dev.mysql.com/doc/refman/8.0/en/partitioning.html
http://mysqlserverteam.com/the-mysql-8-0-0-milestone-release.../Deprecate and remove partitioning storage engine (WL#8971) — This work by Sivert Sørumgård deprecates (5.7) and removes (8.0) the partitioning storage engine (ha_partition). The responsibility for partitioning has been moved down to the storage engine layer. InnoDB supports partitioning from 5.7 and onwards.
> InnoDB supports partitioning from 5.7 and onwards.Ну и? Перенесли в InnoDB, будут дальше пилить там.
> Tokudb: https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb...
> Плюс получите очень эффективное сжатие, и большую скорость, чем даже у Postgresql.
> И SSD проживет дольше, чем под Postgresql, если такая связка используется.Полнотекстовый поиск не умеет
> Полнотекстовый поиск не умеетSphinx для этого есть.
Кастомное решение, для массовоого хостинга бесполезно.
Эластик серч на джаве тоже бесполезен. Firebird?
Sphinx для говнохостинга не вариант, согласен.
Но, справедливости ради, в InnoDB FULLTEXT из MyISAM совсем не давно перекачивал. Может быть и в току добавят, как и форей ключ.
Постгрес на массовом говнохостинге тоже редкость. Но здесь-то уж я не понимаю, кому нужен говнохостинг, когда виртуалки давно уже стоят столько же, сколько shared. Понимаю, там, сеошники-вебмастера, которые консоли боятся...
А это бесплатный хостинг, вируалки от 3.99
Ну, если ваше время на борьбу с ограничениями бесплатного хостинга дешевле 4 баксов в месяц...
Если мой рейт 20 баксов в месяц, то моя борьба с ограничениями заказчику отобьется уже через 5 месяцев. А можно сделать и за пол месяца
> мой рейт 20 баксов в месяцПрисылайте резюме срочно! Дам 21.
В том то и дело, есть куча движков, на любой вкус. У InnoDB сложилась кривая архитектура, но это вовсе не проблема.
Ну марию они все равно не переплюнули, она 10 уже))))
Последний раз, когда пытался восстановить InnoDB таблицы после падения системы, оно мне писало, что InnoDB принципиально не восстанавливается. Это уже поправили?
Как правило так и есть. Если у тебя включен innodb_file_per_table - то есть какие-то шансы, а ibdata - это один большой блоб.С другой стороны, покажите мне такую базу, которую с лёгкостью можно восстановить при физической порче файлов на диске. Посгрес, на который фапают в комментариях выше, убивается напрочь при удалении ОДНОГО файла ЛОГА ТРАНЗАКЦИЙ, даже не данных.
> ОДНОГО файла ЛОГА ТРАНЗАКЦИЙ, даже не данных.Отличная готовность...
Есть много отличных систем, где все убивается от удаления одного файла. Может просто не надо удалять важные файлы?
Замечательный ответ по уровню де6илизма.- Как писать безглючный софт?
- Просто делай ошибок в программах!Гениально.
Если вы взяли и удалили файл в папке постгри, это баг не постгри, а ваш.
У постгри нельзя удалять лог транзакций. Про это есть даже анекдот:
— Я тут типа удалил несколько Гб лог-файлов из каталога pg_xlog, чтобы освободить место на диске. Теперь моя база данных не взлетает.
— Ой-вей! Кхе-кхе… А когда говорите в последний раз резервную копию делали?
похачили, это баг дизайна
> похачили, это баг дизайнаНу если в ОС файл ядра удалить, оно ОС перестанет грузиться.
Тоже баг дизайна.
> ОДНОГО файла ЛОГА ТРАНЗАКЦИЙ, даже не данныOracle does the same!
DB2?
> отмечается закат хранилищаЭто по-каковски?
А когда будет релиз версии 8.0?
Почему 8? Почему не MySQL 10?
А какое "хранилище" теперь будет вместо MyISAM?
И как мне перегнать базы из хранилища MyISAM на новое хранилище?Никогда не задумывался о том, какое хранилище назначается создаваемым мною таблицам. Сейчас посмотрел - оказалось, что всем таблицам в моих базах всегда назначалось хранилище MyISAM.
Как теперь перегонять базы с таблицами со старого хранилища на новое? Выгнать базы в дампы, поменять всем таблицам руками фразу ENGINE=MyISAM на ENGINE=НОВОЕ_ХРАНИЛИЩЕ и перезагнать такие дампы обратно в базы?
InnoDB у Oracle и Percona.
Aria у MariaDB.
> InnoDB у Oracle и Percona.
> Aria у MariaDB.А у Mysql? И как базы со старым типом хранилища перегнать в базы с новым типом хранилища?
Mysql это и есть Oracle
