|
2.2, KonstantinB (ok), 23:35, 19/04/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
Это лучше, чем MariaDB, они выпилили myisam насовсем, в том числе из служебных таблиц.
| |
|
3.5, Gemorroj (ok), 00:11, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
вот тоже уже думаю обратно на ванильный mysql с марии переезжать.
честный json, sys схема... в то время как мария начала ломать совместимость с оригинальным mysql (тот же json), что сильно снижает ее привлекательность.
| |
|
4.7, KonstantinB (ok), 00:15, 20/04/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Еще CTE и window-функции завезли.
Я с бетой игрался, отлично, уже прям настоящая РСУБД, скоро постгрес догонит.
| |
|
|
6.70, Аноним (-), 09:30, 21/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Segmentation fault
Обычно перестаёт быть страшно к N.X.20-26, а в важных местах к N.X.40
Но ходят слухи, что минорная нумерация версий тоже поменяется/поменялась.
| |
|
|
|
5.20, KonstantinB (ok), 06:00, 20/04/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Percona умеет половину из Maria и Mysql 8.0
Transactional data dictionary не умеют, это самое главное. Тут я восхищаюсь объемом проделанной работы. Системные словари относятся к самому древнему окаменевшему коду, который Монти писал на коленке в далеких девяностых, и myisam был прибит гвоздями наглухо кондовым хардкодом везде, где можно и нельзя.
| |
5.69, Аноним (-), 09:27, 21/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Percona умеет половину из Maria и Mysql 8.0
Percona не пилит новые божественные фичи. Percona Server это ванильный оракловый MySQL + набор фишек повышающих производительность (чаще меньше чем следующий мажорный релиз от Oracle) + удобства диагностики (больше инфы в slowlog, userstats) + энтерпрайз фишки под GPL вроде PAM audit_plugin.
MariaDB пилят свои фишки отдельно, на своём форке mysql 5.5, без оглядки что это надо/можно будет объединить с Oracle MySQL.
Так что Percona Server 8.0 выйдет через пару месяцев и будет уметь то же что и MySQL 8.0, а фишки из MariaDB доступны только плагинные.
Никакой магии нет, все три компании занимаются разным в плане разработки.
| |
|
4.40, feudor (ok), 11:09, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
мария начала ломать совместимость с оригинальным mysql хорошая шутка.
| |
|
|
|
3.9, KonstantinB (ok), 00:33, 20/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Чтобы с озвученной Uber-ом проблемой столкнуться, нужен особый характер нагрузки - множество апдейтов в секунду, затрагивающих индекс. Для большинства проектов это не критично.
| |
|
4.24, Аноним (-), 07:21, 20/04/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
Из статьи следует, что апдейты индексированнного поля и неиндексированного одинаково тяжеловесны в Постгри.
Использование СУБД файлового кеша ОСи убило ваапще.
Подумывал опробывать Постги, но теперь обожду.
| |
|
|
6.71, Аноним (-), 09:38, 21/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Использование СУБД файлового кеша ОСи убило ваапще.
> И чем же?
Если горячая страничка (на чтение) вытеснится из кеша ОС, сразу пачка одновременных запросов может заблокироваться, за это время придёт ещё пачка запросов и база будет работать медленнее из-за скачка нагрузки (больше тредов/процессов - больше блокировок).
Эту проблему можно убрать, если кешировать в shared memory сегменте базы, но без direct io одни и те же данные будут и в shared memory и в кеше ОС, а значит надо для одних и тех же данных закупать на 20-30% больше оперативной памяти если база не работает/не эфективно работает с direct io.
| |
|
7.86, Аноним (-), 22:31, 24/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> одни и те же данные будут и в shared memory и в кеше ОС
Как долго? Это не так просто оценить, у shared_buffers и у кеша ОС есть алгоритмы вытеснения не используемых данных, в конечном счёте в shared_buffers останутся горячие данные, а в кеше ОС — тёплые (другие), потому что данные находящиеся в shared_buffers не запрашиваются у ОС и вытесняются из кеша, не так ли?
| |
|
|
5.62, KonstantinB (ok), 04:29, 21/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением. Хранилище постгреса проектировалось в те далекие времена, когда никаких O_DIRECT не было даже в планах. В условиях какого-нибудь ядра 1.4 или freebsd 3 это было наиболее эффективным решением. Оттуда же и пачки процессов и shared memory - никаких epoll-ов и прочих kevent тоже не было, с тредами все было печально. Но, надо заметить, все это и сейчас весьма неплохо работает.
| |
|
6.78, нах (?), 21:38, 22/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> То, что сейчас кажется дикостью, 20 лет назад было оптимальным решением.
и пока линуксеры не доломали совместимость с нормальными юниксами - вполне пристойно работает.
родовая травма постгреза - его причудливейший формат storage, корнями уходящий в великую бесполезно-фичу time-travel (не работающую со времен postgresql95)
с вечным vacuum ("мы его уже совсем-совсем deprecated, он ненужен-ненужен...а, нет, разумеется он будет и дальше вызываться из внутреннего планировщика в самые неподходящие моменты, мы не об этом") и вечным разрастанием индексов.
Что новый-модный zheap решит эти проблемы не создав попутно все те же что у myisam и еще пачку уникальных - что-то вот не верится.
| |
|
|
4.55, letsmac (ok), 15:51, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы с этой проблемой столкнуться надо написать оптимизированную логику под MySQL, а потом перенести эту логику на Postgres. У которой свои оптимизации.
>>Для большинства проектов это не критично.
Postgres не любит апдейтов, как и любой версионник. Для кучи апдейтов лучше уж NoSQL использовать.
| |
|
5.64, funny. falcon (?), 08:23, 21/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Извините, но Innodb тоже версионник. Однока он лучше сравляется спробоемой потому, что у него быстрее всего доступна именно последняя версия строки.
В постгрессе же последняя версия строки чаще всего попадает в экзкьютор последней.
| |
|
|
3.10, Аноним (-), 00:33, 20/04/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Не нужен кому? PostgreSQL это из разряда MSSQL, продукции Oracle, Sybase.
З.Ы. топить за MyISAM не смешно и не весело ни разу.
| |
|
4.11, Аноним (-), 00:40, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
А чем myisam плох для определённых случаев? Вот есть десяток девелоперских баз. На myisam заливка дампа на два с половиной гигабайта с прода занимает от силы 10 минут. На Inno/XtraDB - в лучшем случае час, и всякие игрища с параметрами в my.cnf и системной схеме не особо помогают.
| |
|
5.12, KonstantinB (ok), 00:58, 20/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для девелоперской базы никто не мешает остановить mysqld и ручками скопировать innodb-файлы.
| |
|
6.17, angra (ok), 02:52, 20/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потом попробовать стартануть мускул, почитать ругань, а если он таки стартанул, то попытаться найти таблицы и обнаружить их отсутствие. Повторить процесс такого горячего копирования несколько раз, до тех пор пока не придет осознание, что ты что-то делаешь неправильно. Потом пойти почитать про кучу дополнительных телодвижений и условий, необходимых для использования такого метода с innodb.
| |
|
|
8.27, angra (ok), 07:50, 20/04/2018 [^] [^^] [^^^] [ответить] | +/– | Я не говорил, что сложно или невыполнимо Но простое копирование как с MYISAM пр... текст свёрнут, показать | |
|
9.72, Аноним (-), 10:00, 21/04/2018 [^] [^^] [^^^] [ответить] | +/– | Нет утилиты официальной, чтобы бекапить всю базу и разворачивать её с помощью tr... текст свёрнут, показать | |
|
|
7.22, Аноним (-), 06:58, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Если останавливают процессы, то это не горячее а холодное копирование.
| |
|
8.25, angra (ok), 07:41, 20/04/2018 [^] [^^] [^^^] [ответить] | +/– | Из контекста остановка продакшена не предусматривалась и про использование репли... текст свёрнут, показать | |
|
|
10.38, ыы (?), 11:06, 20/04/2018 [^] [^^] [^^^] [ответить] | +/– | там может быть все что угодно например 386DX2 какой-то хостинг с 64 мегами о... текст свёрнут, показать | |
|
|
12.84, angra (ok), 04:55, 24/04/2018 [^] [^^] [^^^] [ответить] | +/– | Да уж, заменить hdd на ssd тот еже фокус настройка Предлагаю не менее эффективн... текст свёрнут, показать | |
|
|
|
9.53, Аноним (-), 13:51, 20/04/2018 [^] [^^] [^^^] [ответить] | +/– | Это была поправка на конкретное высказывание http www opennet ru openforum vsl... текст свёрнут, показать | |
|
|
|
|
|
|
3.13, Аноним (-), 01:05, 20/04/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Статья устаревшая из-за старой используемой версии у Убера. Хотя, конечно, никто не без проблем.
| |
|
4.14, KonstantinB (ok), 01:09, 20/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да пофиг какая версия, основное там - это родовая проблема с организацией данных. Из-за нее, кстати, и нужен тяжелый VACUUM. Патчи в новых версиях только смягчают проблему, но не решают.
Все остальные пункты - действительно мелкие придирки.
| |
|
3.81, fi (ok), 14:30, 23/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
этот старый вброс давно разобран по косточкам — там в основном проблемы разраба, плюс ему очен хотелось MySQL
| |
|
2.16, rshadow (ok), 01:37, 20/04/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
Постгря плохо работает с индексами. И разрабы абсолютно упираются от создания инструмента ручного управления ими. Так что директивы и невидимые индексы выглядят вкусно.
| |
|
3.33, Кабан ЛяЛя (?), 09:11, 20/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это где она плохо работает?
Хоть один пример...
За ручное управление индексами "по шапке"!
| |
|
|
5.50, rshadow (ok), 13:16, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну да. Начиная с COUNT(*) который полным сканированием определяется, заканчивая явными глюками оптимизатора, которые может когда нибудь и починят.
| |
|
6.74, Аноним (-), 10:28, 21/04/2018 [^] [^^] [^^^] [ответить] | +/– | В 5 7, кстати select count чуток ускорили InnoDB SELECT COUNT FROM t sta... большой текст свёрнут, показать | |
|
|
4.51, rshadow (ok), 13:21, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Совершенно с вами согласен. Только для сферического мира где планировщик не глючит, ALTER TABLE...NOT NULL всегда делается мгновенно на боевой бд, и вообще есть беспростойный апгрейд версии через репликацию.
Очень хочется просто вводить команды, а оно само оптимизировалось, расползалось по кластеру, делалось мгновенно и без глюков.
| |
|
|
|
1.32, Аноним (-), 09:07, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Про партицирование ничего не сказали. Его поправили? Можно теперь совмещать в таблице партиции разных движков?
| |
|
2.34, Ануним (?), 10:03, 20/04/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
О, помню этот баг. Помнится, из-за него я рабочий проект потребовал на MSSQL перевести.
| |
|
3.48, Аноним (-), 12:07, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
А мы накостыляли кучу запросов, отображений, триггеров, чтобы работать с разными устройствами хранения данных в рамках одной таблицы. Хотя фактически это были разные таблицы. В итоге забили, перевели на SSD, которые мрут как мухи, но обеспечивают стабильную поддержку ПО.
Не понятно, зачем вводить в протокол функционал, который они и не собирались поддерживать. Подразнить?...
| |
|
2.65, Аноним (-), 08:29, 21/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Наоборот выпилили эту возможность:
https://dev.mysql.com/doc/mysql-partitioning-excerpt/8.0/en/partitioning.html
In MySQL 8.0, partitioning support is provided by the InnoDB storage engine. (The NDB storage engine used by MySQL Cluster also provides partitioning support, but NDB is not included in MySQL 8.0.)
MySQL 8.0 does not currently support partitioning of tables using any storage engine other than InnoDB, such as MyISAM. An attempt to create a partitioned tables using a storage engine that does not supply native partitioning support fails with ER_CHECK_NOT_IMPLEMENTED.
| |
|
1.35, luserz (?), 10:36, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
параллельность добавили выполнения запросов? или всё так же в одну каску молотит каждый запрос?
| |
1.36, анонимус (??), 10:52, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц? PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.
Почему я не могу аггрегировать данные в колонку при группировке с сохранением типов? GROUP_CONCAT возвращает строку.
Когда функция GROUP_CONCAT перестанет тихой сапой резать результирующую строку, в случае если строка превышает значение установленное в group_concat_max_len?
Такого поведения там полно. И пока его не пофиксят MySQL так и останется недоСУБД.
| |
|
2.37, Фуррь (ok), 10:59, 20/04/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
>PostgreSQL это умеет. Я не говорю уже про Oracle/MsSQL.
Обычно такие претензии возникают из-за непонимания того, что MySQL - это маленькая быстрая пони, и её нельзя грузить, как ломовую лошадь.
| |
|
3.76, Адноним (?), 14:34, 22/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Маленькая пони полная Нонна из сомнительных решений и память она жрет в разы больше pgsql
| |
|
2.42, Аноним (-), 11:16, 20/04/2018 [^] [^^] [^^^] [ответить] | +/– | А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц ... большой текст свёрнут, показать | |
|
3.54, KonstantinB (ok), 15:05, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> А когда MySQL начнет поддерживать транзакции при изменении структуры таблиц?
Транзакционные системные словари и atomic DDL в 8.0 сделали, так что скоро. Вроде уже ничто не мешает.
| |
|
2.43, Аноним (-), 11:18, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Такого поведения там полно. И пока его не пофиксят MySQL так и
> останется недоСУБД.
Так она по определению теперь такая, а так-же тестовый полигон и обучалка для будущего использования промышленной БД от oracle.
| |
|
1.47, rvs2016 (ok), 11:45, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Версия 8.0 обусловлена сменой нумерации версий,
> релиз выпущен следом за 5.7 вместо версии 5.8.
Не понял прикола. Почему в смене версий с 5.7 на сразу 8.0 упор делается на то, что не было промежуточных версий с непонятными номерами типа 5.8 вместо указания на отсутствие более логичных номеров типа 6.0 да 7.0?
ps: С версиями типа 6.* вроде прикол много лет назад ходил такой: начали делать шестые версии, а потом забросили и откатились обратно на пятые. А с седьмыми номерами прикол какой, в чём?
| |
|
2.57, Аноним (-), 19:05, 20/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Тут как с джавой логика, минорная циферка переехала в мажорную, потому что по факту 5.х это давно уже не минорные релизы.
| |
|
1.49, Аноним (-), 12:48, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то появилась в транзакции уже? SELECT ... FOR UPDATE?
| |
|
2.67, Аноним (-), 08:53, 21/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Чего-то я не понял блокировка строк для обновления дальнейшего в таблице то
> появилась в транзакции уже? SELECT ... FOR UPDATE?
SELECT FOR UPDATE был уже в 4.0, 2002 год, почти 16 лет назад.
В 8.0 добавили возможность при использовании select for update либо выдать ошибку как только натолкнёмся на строчку заблокированную другой транзакцией NOWAIT (модифицированную или заблокированную S F U) либо молча пропускать строчки заблокированные другими транзакциями SKIP LOCKED.
Сходу что приходит в голову, такие фишки позволяют делать очереди с несколькими обработчиками на кроне/event scheduler.
| |
|
1.60, Vitaliy Blats (?), 20:35, 20/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Лучше бы не хренотень всякую придумывали, а сделали то, о чем ноют в интернетике с момента создания InnoDB - вменяемого рекавери. Которое именно срекаверит, максимум проигнорирует транзакции с ошибками и восстановит БД, а не высрет в лог кучу непонятной срани, а при попытке восстановить скажет "Ололо Got error: 1146: Table ‘database.table’ doesn’t exist when using бла бла бла"
| |
|
2.68, Аноним (-), 09:07, 21/04/2018 [^] [^^] [^^^] [ответить] | +/– | InnoDB модифицирует данные по месту, Если лог транзакций физически повреждён, то... большой текст свёрнут, показать | |
|
3.77, нах (?), 18:16, 22/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются
> вникуда (потому что это более свежая версия страницы)
откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?
| |
|
4.79, Аноним (-), 21:49, 22/04/2018 [^] [^^] [^^^] [ответить] | +/– | В каждой странице содержится ссылка на следующую и предыдущую Если мы сделали с... большой текст свёрнут, показать | |
|
5.80, нах (?), 01:12, 23/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска.
то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006).
binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.
| |
|
|
|
|
1.87, Alex (??), 23:45, 04/12/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Мда.. вышел порт 8.0.12_1, затем 8.0.12_2 и не собирается.. откатывать обратно на 5.7...
mysql80-server-8.0.12_2 is vulnerable:
MySQL -- multiple vulnerabilities
CVE: CVE-2018-3286
CVE: CVE-2018-3283
CVE: CVE-2018-3284
CVE: CVE-2018-3282
CVE: CVE-2018-3279
CVE: CVE-2018-3278
CVE: CVE-2018-3161
CVE: CVE-2018-3186
CVE: CVE-2018-3280
CVE: CVE-2018-3212
CVE: CVE-2018-3170
CVE: CVE-2018-3200
CVE: CVE-2018-3173
CVE: CVE-2018-3162
CVE: CVE-2018-3277
CVE: CVE-2018-3171
CVE: CVE-2018-3174
CVE: CVE-2018-3187
CVE: CVE-2018-3247
CVE: CVE-2018-3195
CVE: CVE-2018-3185
CVE: CVE-2018-3144
CVE: CVE-2018-3145
CVE: CVE-2018-3133
CVE: CVE-2018-3203
CVE: CVE-2018-3137
CVE: CVE-2018-3182
CVE: CVE-2018-3251
CVE: CVE-2018-3156
CVE: CVE-2018-3143
CVE: CVE-2018-3155
CVE: CVE-2016-9843
WWW: https://vuxml.FreeBSD.org/freebsd/ec5072b0-d43a-11e8-a6d2-b499baebfeaf.html
| |
|