|
|
3.123, Аноним (-), 20:15, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Единственная там удобная фишка -- это дефрагментация.
В InnoDB тоже фейсбук добавил дефрагментацию :P
| |
|
|
1.2, A.Stahl (ok), 09:51, 13/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>отмечается закат
Хм. Мерзко звучит. Может "происходит отказ от" или что-то в этом роде?
>выровнена
Может всё-таки "выравнена" от слова "равенство", а не "выровнена" от слова "ровно"?
| |
|
|
3.43, Аноним (-), 11:33, 13/10/2016 [^] [^^] [^^^] [ответить]
| –5 +/– |
клоун: это называется "чередование". Весьма распространённое (и жутко неудобное для изучающих русский язык иностранцев) явление.
http://licey.net/free/4-russkii_yazyk/39-kurs_russkogo_yazyka_fonetika__slovo
Все слова являются исключениями. Правила есть, но они работают 50:50. Так, если после корня стоит "т" и ещё какие-нибудь буквы, то "о" часто меняется на "а": рост - росли - расти - растить, но мост - мостить.
...
По сути он прав, слово "закат" в данном контексте употреблено неверно. Правильнее было бы употребить "отказ".
| |
|
|
1.3, GreenX (ok), 09:56, 13/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как будто, MySQL какая то секта, а MyISAM важная эпоха... а по сути так и есть. :)
| |
|
2.111, KonstantinB (ok), 16:22, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Отказ от myisam для системных словарей - это действительно прямо ВЕХА. И там настолько это было гвоздями прибито в коде, что работа проделана просто огромная.
Неверсионность DDL всегда создавала кучу проблем и была одним из ключевых недостатков mysql.
| |
|
|
|
3.103, SysA (?), 16:01, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Нет ни малейшей причины не использовать 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
| |
|
4.127, anomymous (?), 23:08, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
У нас Confluence на MariaDB Galera работает. С Galera есть свои тонкости, а вот если без галёры - полный drop-in replacement без особых проблем.
| |
|
|
2.56, Аноним (-), 12:43, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
нет никаких причин переходить на MariaDB - учитывая страсть автора к странным лицензиям и перепродаже воздуха.
| |
|
3.130, XoRe (ok), 02:22, 14/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> нет никаких причин переходить на MariaDB - учитывая страсть автора к странным
> лицензиям и перепродаже воздуха.
А у Оракла страсть к странному развитию продукта, которое со стороны может показаться закапыванием. У всего есть плюсы и минусы.
| |
|
|
|
2.165, irinat (ok), 00:38, 16/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Chrome уже выполнил главный квест прикладного ПО — превращение в операционную систему. Его не догнать.
| |
|
1.9, Ilya Indigo (ok), 10:23, 13/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
> версия 8.0 будет выпущена следом за 5.7, вместо 5.8
Это запоздалый и кривой бекпорт из MariaDB, или это вирус Хрома начал поражать вэб-технологии?
У PHP была объективная причина, пропустить 6-ую версию, и по случайности совпало, что вместо 5.7 вышла 7.0.
MariaDB, хотела чтобы считали, что у ней писька длиннее, чем у PostrgeSQL.
Но какой смысл мускулу переходить на 8-ую версию?
| |
|
2.11, Аноним (-), 10:25, 13/10/2016 [^] [^^] [^^^] [ответить]
| –8 +/– |
У MariaDB писька коротка, но еще перерастет таковую у PostrgeSQL.
| |
2.12, Аноним (-), 10:29, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Много фундаментальных изменений -> необходима смена мажорной версии. 6 версию пропустили т.к. была. 7 версию перескочили т.к. нынче трендово.
| |
|
3.15, Ilya Indigo (ok), 10:34, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Много фундаментальных изменений -> необходима смена мажорной версии. 6 версию пропустили
> т.к. была. 7 версию перескочили т.к. нынче трендово.
6-ой версии ни в релизе, ни в учебниках не было.
В 5.5 то же много чего фундаментального поменяли, но на 6 не перескакивали.
И с каких это пор цифра 7 перестала быть трендовой?
| |
|
4.18, Аноним (-), 10:36, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
6.0 версия была, но была заморожена еще на стадии альфа-тестирования
| |
|
5.42, Ilya Indigo (ok), 11:30, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> 6.0 версия была, но была заморожена еще на стадии альфа-тестирования
Ну мало ли, что было несколько лет назад в планах у разработчиков.
Насколько я понял, эта версия выщла как 5.5.
В PHP была схожая ситуация, но её успели много кто потестировать, её много кто ожидал, не меньше чем Perl 6, изменения там были колоссальные, и вышла она как 5.4, но главное, информация про её скорый релиз, и частичную функциональность, утекла во множество учебников. А тут лишь в Вики можно прочитать, что оказывается давным-давно, в далёкой-далёкой галактике...
Причина пропуска никак не объективная.
| |
|
4.19, Аноним (-), 10:38, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Имелось ввиду не 7 перескакивать трендово, а трендово скакать вообще. Чем они хуже мелкософта?
| |
|
5.47, Аноним (-), 11:48, 13/10/2016 [^] [^^] [^^^] [ответить]
| –8 +/– |
клоун: у Майкрософта то как раз всё... сложно :).
"Windows 10" - это маркетинговое название, не имеющее никакого отношения к внутренней нумерации, также как и "Windows 7".
Функция GetVersionEx возвращает 6.2 для W8 и 6.3 для W8 (с обновлениями) и W10, что тонко намекает на количество изменений.
Чтобы определить, что это именно W10 необходимо вызвать новую функцию - IsWindows10OrGreater(), а старые (GetVersion, GetVersionEx) считаются устаревшими и не должны больше вызываться.
| |
|
6.55, pkdr (ok), 12:13, 13/10/2016 [^] [^^] [^^^] [ответить]
| +10 +/– |
Неужели ты думаешь, что кому-то, кроме того мелкого сотрудника M$, который направил тебя на этот сайт, интересно, что там возвращают кривые функции в замороченном поделии индусов-извращенцев из M$?
| |
|
|
|
|
2.16, iPony (?), 10:34, 13/10/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
Ну что за позерство?
По-моему логичная смена нумерации. Раньше были 5.6, 5.7, которые вроде как выглядят минорными, но такими не являются. Изменений в новой достаточно.
Версию к тому же приравнивают к MySQL Cluster.
В итоге всем удобно, а Вы рассуждайте и дальше про длину кхе-кхе.
| |
|
|
4.25, iPony (?), 10:45, 13/10/2016 [^] [^^] [^^^] [ответить]
| –4 +/– |
Для людей не хотящих думать, а занимающихся популизмом - да.
| |
4.108, soarin (ok), 16:15, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ну таково мнение Оракла, а Вы с воплями "как же так можно нумеровать" действительно можете идти куда подальше. Нормальных людей не очень цифры версии волнуют.
> Версию к тому же приравнивают к MySQL Cluster
А это и есть реальная причина.
PS: а свои "смишные" картинки оставьте, пожалуйста, для других ресурсов, если нечего сказать.
| |
|
|
2.22, Аноним (-), 10:41, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Всё просто. Проект завис на версии 5. Вот они 5 отбросили, и сделали минорную циферь мажорной. Всё вполне логично. Ничего не перескакивали.
| |
|
3.160, Аноним (-), 11:51, 15/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Поддерживаю, это первое, о чём я подумал, когда увидел 5.5 → 5.6 → (5.)7
| |
|
2.61, й (?), 13:01, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
ой, не застали вы slackware 7.0 задолго до хрома. там к нему в комлекте шло чудесное описание, почему была версия 4.0, а стала 7.0
| |
|
3.62, й (?), 13:02, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
или solaris 7 после 2.6 незадолго до слаквари
| |
|
4.161, Аноним (-), 11:52, 15/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
После (2.)6 идёт 7, потому что в (2.) больше нет необходимости, всё правильно.
| |
|
|
|
1.10, Аноним (-), 10:24, 13/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
InnoDB с ее жором памяти тоже пора закатывать и убирать в дальний угол кладовки.
| |
|
2.13, Ilya Indigo (ok), 10:30, 13/10/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
> InnoDB с ее жором памяти тоже пора закатывать и убирать в дальний угол кладовки.
Те кто так считают, уже давно перелезли на PostgreSQL, а то и изначально используют его.
| |
|
3.17, YetAnotherOnanym (ok), 10:35, 13/10/2016 [^] [^^] [^^^] [ответить]
| –4 +/– |
> давно перелезли на PostgreSQL, а то и
> изначально используют его.
Зачем Вы разрушаете уютный мир выпускников трёхмесячных курсов веб-дизайна? MySQL - их первая любовь на всю жизнь.
| |
|
4.36, Аноним (-), 11:17, 13/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
MySQL - моя первая любовь. И серьезно разобравшись в вопросе я понял, под мой круг задач MySQL оптимальнее. И я вообще не понимаю тот фанатизм, который развернулся вокруг PostgreSQL. На мой взгляд все эти люди просто некомпетентны в вопросе, повелись на мишуру.
| |
|
5.67, Аноним (-), 13:13, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Mysql тупо быстрее, предсказуемее (потому что блокировочник), проще в обслуживании и примитивнее в использовании. Для веба в самый раз.
| |
|
6.86, all_glory_to_the_hypnotoad (ok), 14:21, 13/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Mysql тупо быстрее, предсказуемее
> потому что блокировочник
Ага, разобрался он в вопросе. Видишь, мускулем пользуются только одни идиоты не способные хоть немного понять как работает ПО которым они пользуются.
| |
6.132, XoRe (ok), 02:31, 14/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> предсказуемее
Ну, с MyISAM точно нет, т.к. нет нормальной транзакционности.
Имхо, лучше сказать, что вы её лучше изучили. Но это не является объективным плюсом именно mysql.
| |
|
|
|
3.21, Gemorroj (ok), 10:40, 13/10/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
к сожалению есть масса легаси кода, и крупных проектов где просто так БД не сменишь. так что mysql нужно по возможности тоже допиливать.
| |
|
4.33, Ilya Indigo (ok), 11:11, 13/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
С этим я не спорю. Я говорю за новые проекты и за те, которые не слишком завязаны на InnoDB или прочие движки.
| |
|
3.24, iPony (?), 10:43, 13/10/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
Так только позеры считают и религиозные фанатики.
Нормальному человеку понятно, что MySQL и PostgreSQL - это ну очень разные инструменты. И в зависимости от поставленной задачи и конкретных условий всё сильно меняется, поэтому ответа на вопрос "Что лучше MySQL или PostgreSQL?" - нет.
| |
|
4.26, Gemorroj (ok), 10:46, 13/10/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
>> MySQL и PostgreSQL - это ну очень разные инструменты
можно подробнее? (реально интересно, это не троллинг)
| |
|
5.32, Аноним (-), 11:06, 13/10/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Не знаю что имел ввиду iPony, для меня решающая разница - поддержка движков таблиц. Под каждую задачу я могу выбрать таблицу с оптимальной для нее структурой хранения данных. Под специфические задачи я могу написать свой табличный движок. В версии 8.0 добавят найтивное партицирование, можно будет формировать гибридные таблицы. В PostgresSQL такого никогда не будет. Зато они не тратя время на поддержку движков действительно здорово продвинулись в других вещах, без которых, впрочем, можно обойтись.
| |
|
6.35, Ilya Indigo (ok), 11:16, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> без которых, впрочем, можно обойтись.
Это субъективное мнение.
Я вот думаю, что при наличии приемлемого встроенного движка, без поддержки сторонних движков вполне можно обойтись.
| |
|
7.40, Аноним (-), 11:26, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Разница между MVCC движками и тем что в MyISAM огромна, другое дело что в MySQL почему-то его решили грохнуть.
| |
|
8.65, Аноним (-), 13:08, 13/10/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Посмотри код myisam - и вопрос отпадёт сам собой Он чудовищно написан, а джедае... текст свёрнут, показать | |
|
|
6.38, Gemorroj (ok), 11:19, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
По факту почти везде innodb. memory какой-то тормознутый (лок на уровне таблицы при insert, например, чего стоит), archive ненадежный (лично приходилось несколько раз восстанавливать).
| |
6.124, anonymous (??), 20:21, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
>В PostgresSQL такого никогда не будет.
Отвечаешь?
Вообще у разработчиков давно в планах поддержка взаимозаменяемых движков, сейчас производителям проприетарных дб на базе постгресса приходиться форкать весь постргес, что мешает им контрибьютить изменения обратно.
| |
|
|
|
3.30, Аноним (-), 10:54, 13/10/2016 [^] [^^] [^^^] [ответить]
| –6 +/– |
MySQL очень гибкая. Назовите любую задачу и на MySQL её можно решить значительно эффективнее, чем на PostgreSQL. Главное чтобы руки из нужного места росли, чем не славятся фанатики PostgreSQL.
| |
|
4.41, Аноним (-), 11:27, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> MySQL очень гибкая. Назовите любую задачу и на MySQL её можно решить
> значительно эффективнее, чем на PostgreSQL. Главное чтобы руки из нужного места
> росли, чем не славятся фанатики PostgreSQL.
Триггеры?
| |
|
5.70, _hide_ (ok), 13:24, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
В 5.7 всё стало нормально. Почти не осталось непонятных ожиданий "пока кто-то схему отпустит" и прочих "левых" блокировок, которые возникали потому что из after триггера запускали обновление другой таблицы, которая в это время была занята (да и ещё MyISAM-овская). Поэтому и ставили задержку в 10-15 секунд на заброс - такая блокировка сама отваливалась через таймаут. Сейчас этого нет, InnoDB почти повзрослел и покрывает большую часть функций "тупо хранить в табличке и не терять связей". Ну да, наследования таблиц и структур нет и не будет, но задач, когда необходимо один набор данных расширять у современных разработчиков почти нет.
| |
|
6.95, Аноним (-), 14:55, 13/10/2016 [^] [^^] [^^^] [ответить] | +/– | Be aware of that MySQL does foreign key checks BEFORE invoking any trigger So i... большой текст свёрнут, показать | |
|
|
4.48, Ilya Indigo (ok), 11:48, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> MySQL очень гибкая. Назовите любую задачу и на MySQL её можно решить
> значительно эффективнее, чем на PostgreSQL. Главное чтобы руки из нужного места
> росли, чем не славятся фанатики PostgreSQL.
Ну, например, физическая репликация транзакционного движка.
| |
|
5.105, KonstantinB (ok), 16:04, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Справедливости ради:
> 5. Возможности оптимизации движка, планировщика и т.д.
С этим уже неплохо в последних версиях Марии (в 8-ке, говорят, тоже).
Там уже комбинированный rule-based + cost-based оптимизатор.
> 7. Традиционный функционал для реляционных СУБД, это ссылочная целостность (FOREIGN KEY).
> В мускуле она не всегда нормально работает даже c innodb.
Нормально там все в innodb, если специально (или по отсутствию ума) не использовать средства для отстреливания себе ног, предназначенные для особых случаев.
По остальным пунктам согласен.
| |
|
4.102, KonstantinB (ok), 16:00, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Назовите любую задачу
Эффективный поиск по разреженному набору атрибутов в различных комбинациях (скажем, есть 500 возможных атрибутов, из которых 450 обычно null). Вот как в яндекс-маркете.
В postgresql есть gin и gist-индексы, hstore и jsonb. Что предлагает тут mysql?
| |
|
|
|
7.151, Аноним (-), 13:00, 14/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
"Мама, сматли, я знаю про inverted index!!11"
Т.е. с наличием json в mysql ты обоcpался и тут же стал требовать что-то другое. Ну покажи мне в посгре map-reduce тогда.
| |
|
|
9.163, Аноним (-), 17:11, 15/10/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Теперь открой непосредственно маркет, посмотри на его сайдбар с чекбоксами, прик... текст свёрнут, показать | |
|
|
|
|
|
|
3.31, Аноним (-), 10:56, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Те кто так считают, уже давно используют TokuDB. PostgreSQL в этом смысле не лучше, не надо тут навязывать неправильные решения, если не разбираетесь в сути дела.
| |
|
|
5.75, _hide_ (ok), 13:32, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Те кто так считают, уже давно используют TokuDB.
> Про неё я слышу впервые. Попытка на офф сайте почитать документацию, приводи
> к запросу указания моих данных, чего мне не особо-то и хочется.
> https://learn.percona.com/download-percona-tokudb-7-5-manual
> В SHOW ENGINES в 10-ой Марии её, естественно, нет.
> Поведайте же нам, что это вообще такое?
https://www.opennet.ru/opennews/art.shtml?num=36779
Вообще, очень странный движок, но имеет свою нишу.
| |
|
|
3.37, Аноним (-), 11:19, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Честно, скажите, что есть действительно необходимого в PostgreSQL, чего нет в MySQL?
| |
|
|
|
6.74, Аноним (-), 13:31, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Оптимизатор в MySQL хорош, будем спорить?
В MariaDB больше флагов.
| |
|
7.99, Аноним (-), 15:13, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Выкатывайте примеры, которые вам каждый день жить не дают, посмотрим. Я лично сталкивался с проблемами оптимизатора за 8 лет работы с MySQL только 1 раз.
| |
|
|
|
4.44, Ilya Indigo (ok), 11:40, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Честно, скажите, что есть действительно необходимого в PostgreSQL, чего нет в MySQL?
Физическая репликация.
Более оптимальное распределение памяти.
PL/pgSQL
UPSERT (В MySQL REPLACE не то, а у INSERT ... UPDATE ... корявый и избыточный синтаксис)
тригонометрические ф-ии
И это только то, что читал беглым взглядом.
P.S. Я не хейтер Постреса, я сам сейчас работаю с Марией, но уже задумываюсь о дальнейшем переходе на Пострес, и мне важно именно объективное мнение достоинств и недостатков обоих, хотя и к субъективным мнением прислушиваюсь.
| |
|
5.60, Аноним (-), 12:54, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Физическая репликация
Которая сocёт на разнесённых репликах. Ширину канала можно добавить, а вот RTT не нaе6ёшь.
> PL/pgSQL
> тригонометрические ф-ии
Да это бывает удобно. Однако пихать логику в базу - общепризнанная bad practice, убивает на корню горизонтальную масштабируемость.
> UPSERT
Который добавили только в 9.5 и который является аналогом ON DUPLICATE KEY, существующим уже тыщщу лет как.
> Более оптимальное распределение памяти.
Угу, особенно с её-то моделью "по процессу на коннект". А боунсер - это сторонний костыль.
| |
|
6.104, Аноним (-), 16:02, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> UPSERT
> Который добавили только в 9.5 и который является аналогом ON DUPLICATE KEY,
> существующим уже тыщщу лет как.
не совсем
| |
6.106, KonstantinB (ok), 16:13, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Да это бывает удобно. Однако пихать логику в базу - общепризнанная bad
> practice,
Смотря какую логику.
Бывает логика хранения или валидации данных, которую не выразить простыми constraints, или умышленная денормализация для производительности. И тут триггеры абсолютно уместны.
> убивает на корню горизонтальную масштабируемость.
И каким же образом? Абсолютно перпендикулярные вещи.
| |
|
7.137, Аноним (-), 02:48, 14/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> которую не выразить простыми constraints
Ну приведите пример, что ли. Триггеры - это как раз то, с чего всё начинается. Примерно та же ситуация, что с плюсовыми шаблонами.
> И каким же образом?
А таким, что как только мастер упирается в лимит железа или времени выполнения, то мы оказываемся в жoпе. Мастер-мастер для RDBMS работает или с кучей оговорок или не работает вовсе, а на слейв ты писать не можешь.
| |
|
6.136, XoRe (ok), 02:47, 14/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Физическая репликация
> Которая сocёт на разнесённых репликах. Ширину канала можно добавить, а вот RTT
> не нaе6ёшь.
Интересно про RTT. Чем она мешает? В postgres просто передаются wal файлы. Как вы это настроите, так они и будут передаваться. Если они забираются медленно, нужно просто подкрутить настройки, чтобы мастер их не удалил раньше.
Кроме того, теперь есть replication slots https://habrahabr.ru/post/245847/
Грубо говоря, сервер будет держать wal файлы до тех пор, пока их не заберет последняя реплика.
| |
|
|
8.174, XoRe (ok), 23:34, 03/11/2016 [^] [^^] [^^^] [ответить] | +/– | На графике при задержке 100мс скорость падает с 1Гб с до 100Мб с Если бы это бы... большой текст свёрнут, показать | |
|
|
|
5.64, Аноним (-), 13:05, 13/10/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Более оптимальное распределение памяти.
Берем TokuDB, включаем сжатие и смотрим на сколько экономнее расходуется дисковое пространство. На моих задачах сжатие достигает 5 раз.
Берем MEMORY, кладем в нее скоропортящиеся данные телеметрии. Табличка в 1 гиг летает, Postgresql же просто убъет ssd непрерывной перезаписью.
Берем табличку Archive с полнотабличным сжатием и кидаем в нее все логи. Сжатие при этом достигает 20 и более раз.
Как реализовать таблицу для работы с манчестером или сетевым устройством под MySQL я знаю, а в Postgresql это в принципе не возможно В ней просто ничего не заложено для организации работы с другими устройствами. Postgresql сейчас даже не способна работать с оперативкой без костылей..., о каком распределении может идти речь?
И это всё не включая возможностей версии 8.0, которая позволит создавать гибридные таблицы с любым распределением данных по любым устройствам памяти.
> UPSERT (В MySQL REPLACE не то, а у INSERT ... UPDATE ... корявый и избыточный синтаксис)
UPSERT думаю добавят. Но это не то, без чего нельзя прожить
> тригонометрические ф-ии
Тригонометрические ф-ии в базе я не использую, и мне даже сложно представить зачем они там и для каких задач их наличие там может пригодиться.
| |
|
6.76, Аноним (-), 13:33, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Знатно вы вкатали постгерам,
В mysql мелкие проблемы решаются по мере поступления.
В pgsql для решения проблем нужно привлекать инженеров/архитекторов и кучу дополнительных костылей по бокам.
| |
|
7.79, Ilya Indigo (ok), 13:53, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Справедливости ради, не вижу особого вката.
Для скоропортящихся данных есть redis, хранить логи в DB... , не знаю, может и есть смысл в этом, но я не могу сходу придумать зачем их нужно там хранить, как и любые данные, специфичные для движка Archive.
TokuDB по умолчания в MariaDB нет, и её ещё нужно установить, возможно скомпилировать, а то и перекомпилировать и сервер, и настроить. Чем не костыль?
На говнохостингах на Сентосе это точно не вариант.
| |
|
8.85, Аноним (-), 14:12, 13/10/2016 [^] [^^] [^^^] [ответить] | +1 +/– | MaxScale CreateTableFilter type filter module regexfilter options ignorecase m... текст свёрнут, показать | |
8.98, Аноним (-), 15:10, 13/10/2016 [^] [^^] [^^^] [ответить] | +2 +/– | В MySQL я одним запросом перегоняю нужные данные из оперативки в любую таблицу, ... текст свёрнут, показать | |
|
|
6.93, Stax (ok), 14:49, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы так говорите, будто в постгресе сжатие использовать вам кто-то мешает. Намного проще, причем, чем какие-либо сторонние 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 -
| |
|
|
|
|
|
3.34, Аноним (-), 11:12, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
К сожалению, в этом смысле разницы нет. В обоих движках постраничная организация памяти, приводящая к большим накладным расходам памяти и, фактически, к невозможности эффективно всё это сжимать. TokuDB станет заменой XtraDB и MyISAM.
| |
|
4.51, Аноним (-), 11:58, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
там же куча движков
infinidb
Brighthouse
KFDB
ScaleDB
Spider
PBXT
| |
|
5.54, Ilya Indigo (ok), 12:11, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> там же куча движков
> infinidb
> Brighthouse
> KFDB
> ScaleDB
> Spider
> PBXT
И как подключить хоть один из них?
| |
|
|
|
|
9.97, Аноним (-), 15:07, 13/10/2016 [^] [^^] [^^^] [ответить] | +/– | Внешние ключи, партицирование и многое другое обещают вынести из обязанностей та... текст свёрнут, показать | |
|
|
|
|
9.84, Аноним (-), 14:07, 13/10/2016 [^] [^^] [^^^] [ответить] | +/– | Кастомное решение, для массовоого хостинга бесполезно Эластик серч на джаве тож... текст свёрнут, показать | |
|
|
|
|
5.57, Аноним (-), 12:44, 13/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
В том то и дело, есть куча движков, на любой вкус. У InnoDB сложилась кривая архитектура, но это вовсе не проблема.
| |
|
|
|
|
1.53, Аноним (-), 12:09, 13/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Последний раз, когда пытался восстановить InnoDB таблицы после падения системы, оно мне писало, что InnoDB принципиально не восстанавливается. Это уже поправили?
| |
|
2.63, Аноним (-), 13:02, 13/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как правило так и есть. Если у тебя включен innodb_file_per_table - то есть какие-то шансы, а ibdata - это один большой блоб.
С другой стороны, покажите мне такую базу, которую с лёгкостью можно восстановить при физической порче файлов на диске. Посгрес, на который фапают в комментариях выше, убивается напрочь при удалении ОДНОГО файла ЛОГА ТРАНЗАКЦИЙ, даже не данных.
| |
|
3.71, Аноним (-), 13:24, 13/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> ОДНОГО файла ЛОГА ТРАНЗАКЦИЙ, даже не данных.
Отличная готовность...
| |
3.139, XoRe (ok), 02:51, 14/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Есть много отличных систем, где все убивается от удаления одного файла. Может просто не надо удалять важные файлы?
| |
|
4.145, Аноним (-), 04:51, 14/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Замечательный ответ по уровню де6илизма.
- Как писать безглючный софт?
- Просто делай ошибок в программах!
Гениально.
| |
|
5.156, XoRe (ok), 17:36, 14/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если вы взяли и удалили файл в папке постгри, это баг не постгри, а ваш.
У постгри нельзя удалять лог транзакций. Про это есть даже анекдот:
— Я тут типа удалил несколько Гб лог-файлов из каталога pg_xlog, чтобы освободить место на диске. Теперь моя база данных не взлетает.
— Ой-вей! Кхе-кхе… А когда говорите в последний раз резервную копию делали?
| |
|
|
7.170, XoRe (ok), 19:15, 27/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> похачили, это баг дизайна
Ну если в ОС файл ядра удалить, оно ОС перестанет грузиться.
Тоже баг дизайна.
| |
|
|
|
|
|
|
1.171, rvs2016 (ok), 17:12, 30/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А какое "хранилище" теперь будет вместо MyISAM?
И как мне перегнать базы из хранилища MyISAM на новое хранилище?
Никогда не задумывался о том, какое хранилище назначается создаваемым мною таблицам. Сейчас посмотрел - оказалось, что всем таблицам в моих базах всегда назначалось хранилище MyISAM.
Как теперь перегонять базы с таблицами со старого хранилища на новое? Выгнать базы в дампы, поменять всем таблицам руками фразу ENGINE=MyISAM на ENGINE=НОВОЕ_ХРАНИЛИЩЕ и перезагнать такие дампы обратно в базы?
| |
|
|
3.173, rvs2016 (ok), 02:15, 02/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
> InnoDB у Oracle и Percona.
> Aria у MariaDB.
А у Mysql? И как базы со старым типом хранилища перегнать в базы с новым типом хранилища?
| |
|
|
|