| |
| 2.4, _hide_ (ok), 11:25, 06/12/2021 [^] [^^] [^^^] [ответить]
| +21 +/– |
 >>> всегда использовал слоника
Тот, кто так говорит, явно не мог его использовать 12+ лет назад. Значит использует лет 5 от силы, т.е. для проектов однодневок. Возможно в этом и причины их мимолетности.
>>> детища оракула
Ну это полностью подтверждает сказанное выше
| | |
| |
| 3.90, лютый жабби__ (?), 15:31, 06/12/2021 [^] [^^] [^^^] [ответить]
| –5 +/– | |
>Тот, кто так говорит, явно не мог его использовать 12+ лет назад
бред, помню, даже в 2000-м году делал пару поделок на постгресе и уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых руках, а по фичам даже 21 года назад постгрес был лучше.
хотя для 2021 оба мусор, тк монга рулит )
| | |
| |
| 4.106, _hide_ (ok), 17:00, 06/12/2021 [^] [^^] [^^^] [ответить]
| +5 +/– |
> бред, помню, даже в 2000-м году делал пару поделок на постгресе и
> уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых
> руках, а по фичам даже 21 года назад постгрес был лучше.
Всё зависит от того, чем Вы занимаетесь. При обновлении 10-15 ГБ с ПГ Вы упираетесь в IO и уже можете наращивать скорость только за линейно, у MySQL имеется возможность такие проблемы отсрочить.
> хотя для 2021 оба мусор, тк монга рулит )
Вот всегда хотел спросить, сколько полезных проектов на Монге есть сейчас, старше 5-8 лет? Просто мой поиск мне даёт очень интересные результаты.
Ну и википедия подсказывает, что Монга это... Ну в общем, не база данных, хотя может заменить некоторые простые её функции.
| | |
| |
| 5.164, Степан (?), 02:03, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Работал недавно на проекте, которому уже почти 10 лет и который является топ 1 решением в своем домене в Америке. На нём используется как раз монга. Не сказать что мы, разработчики, рады этому факту, но работает
| | |
|
| 4.165, Аноньимъ (ok), 02:49, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 >слон медленнее мускуля только в кривых руках
В переводе с опеннетского это видимо означает, что нужна команда высококлассных специалистов чтобы его базово настроить.
Мускл же меня никогда не подводил и работал сразу из коробки.
| | |
|
| |
| 4.215, cadmi (?), 13:46, 07/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Когда Вадиму Михееву (работал в соседнем здании и был с ним знаком) в 1995 году понадобилось написать телефонный биллинг для МГТС в Красноярске, он написал половину тогдашнего постгреса :)
| | |
|
| 3.157, Аноним (157), 23:26, 06/12/2021 [^] [^^] [^^^] [ответить] | +1 +/– | Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с 8-й в... большой текст свёрнут, показать | | |
| |
| 4.158, YetAnotherOnanym (ok), 23:36, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 > армия php'шников использовала преимущественно MySQL
> в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов
Чувствуется какая-то связь между этими наблюдениями...
| | |
| 4.161, _hide_ (ok), 00:32, 07/12/2021 [^] [^^] [^^^] [ответить] | +1 +/– | Это Вы про скороть чтения на одинаковом железе или сравниваете корпоративный сер... большой текст свёрнут, показать | | |
| 4.180, моррут (?), 09:44, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения).
при этом вполне синтаксически корректные конструкции в запросе MySQL вполне может сожрать без
каких-либо замечаний, но ничего при этом не сделать.
| | |
| 4.228, Анонимус314 (?), 21:58, 08/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Вот откуда берется это про "нужно настраивать"? Там все основные настройки в конфиге откомментированы и интуитивно понятны, насколько помню (2 года настройкой СУБД не занимался).
| | |
|
|
| 2.18, Ян Злобин (ok), 11:57, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > всегда использовал слоника заместо вот этого вот детища оракула
Ничего вы, батенька, не понимаете в залепухах для прачечных!
| | |
| 2.117, Аноним (117), 19:14, 06/12/2021 [^] [^^] [^^^] [ответить]
| +11 +/– | |
> детища оракула
Вот и выросло поколение...
Хоть википедию бы почитали бы
| | |
|
| 1.2, AleksK (ok), 11:22, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
 Вот кстати тоже не понимаю зачем нужен MySQL если есть Postgres, который уделывает его по всем параметрам.
| | |
| |
| 2.5, _hide_ (ok), 11:27, 06/12/2021 [^] [^^] [^^^] [ответить]
| +7 +/– | |
>>> уделывает его
По каким параметрам?
>>> по всем
А мне казалось, что применение PG -- это очень взвешенное и обоснованное решение.
| | |
| 2.6, funny.falcon (?), 11:30, 06/12/2021 [^] [^^] [^^^] [ответить]
| +8 +/– | |
Не по всем. Я, как любитель PostgreSQL, ответственно заявляю.
Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё актуальны.
| | |
| |
| 3.11, AleksK (ok), 11:40, 06/12/2021 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё
> актуальны.
Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.
| | |
| |
| 4.17, Gemorroj (ok), 11:55, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 миграция на более новые версии у mysql на порядок проще. мультимастер (galera в mysql). некоторый синтаксический сахар (работа с enum, например).
| | |
| |
| |
| 6.22, x3who (?), 12:06, 06/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.
| | |
| |
| 7.23, AleksK (ok), 12:13, 06/12/2021 [^] [^^] [^^^] [ответить]
| –8 +/– | |
> ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.
Вот именно, я работаю со своей объектной моделью, мне пофиг на то что там происходит под капотом. Но с Posgtres для меня все работает быстрее, и админить его ИМХО проще и удобнее.
| | |
| |
| |
| 9.153, AleksK (ok), 23:07, 06/12/2021 [^] [^^] [^^^] [ответить] | –2 +/– | Понятное дело если бы ты её писал то она бы летала и была бы сделана идеально Э... текст свёрнут, показать | | |
|
|
|
|
| 5.40, Аноним (40), 12:55, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>более новые версии
а есть менее новые? Ну или хотя бы более лучшие.
| | |
| 5.47, Ilya Indigo (ok), 13:15, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > (работа с enum, например).
enum в постгресе одна из немногих вещей которая мне понравилась.
В MariaDB я его никогда не использую, так как есть более эффективный tinyint unsigned, а соответствия можно в php массивом в константе класса сохранить.
Но в посгресе нет ни tinyint ни unsigned но можно определить 1 раз enum и вставлять его в 2 и более таблицы, а если нужно модифицировать то делается это 1 раз.
| | |
|
| 4.204, Аноним (204), 11:57, 07/12/2021 [^] [^^] [^^^] [ответить] | +/– | Я мог конечно не так понять, но вроде обоснования были такие Там вроде одна из ... большой текст свёрнут, показать | | |
| |
| 5.249, www2 (??), 07:25, 22/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - нет. Набегающие толпы читающих клиентов могут надолго заблокировать запись для обновления.
А в PostgreSQL каждый читающий клиент будет читать эту запись внутри своей транзакции, а в рамках другой транзакции эта запись будет обновлена, так что следующие читающие клиенты начнут новые транзакции и прочитают уже обновлённую запись.
https://ru.wikipedia.org/wiki/PostgreSQL#%D0%9C%D0%BD%;D0%BE%D0%B3%D0%BE%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(MVCC)
В общем, для сайтиков, где данные обновляются не так часто, а чаще читаются, MySQL, наверное, подойдёт лучше. Если же данные чаще обновляются, чем читаются, то PostgreSQL подойдёт лучше.
| | |
|
|
| 3.34, Cykooz (ok), 12:27, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Насколько помню они вернулись не в совсем обычный MySQL, а в какую-то свою кастомизацию, с помощью которой они из MySQL сделали Key-Value базу данных. Вероятно тогда это было легче сделать в MySQL, т.к. там есть поддержка разных движков для хранения данных. В Postgres она появилась только недавно.
Поэтому не совсем корректно говорить, что они вернулись именно в MySQL, т.к. они фактически перешли на совершенно другой тип базы данных.
| | |
| |
| |
| 5.77, Cykooz (ok), 14:35, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Нет. Key-value у них - это слой абстракции сверху, а не движок.
А, ну да. Но тем не менее они сделали "костыль" поверх MySQL, т.к. именно его движок хорошо показал себя с этим "костылём". С тем же успехом они могли взять готовую Key-Value базу, если бы была в тот момент подходящая под требования. Поэтому не очень корректно приводить пример Uber-а, т.к. они MySQL использовали довольно специфично. Примерно как сравнивать Postgres с Redis.
| | |
|
|
| 3.147, arisu (ok), 21:53, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 > Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё
> актуальны.
так причина «мы не хотим платить специалистам, поэтому наберём макак по объявлениям» всегда будет актуальна.
| | |
|
| 2.42, Ilya Indigo (ok), 13:06, 06/12/2021 [^] [^^] [^^^] [ответить]
| –3 +/– |
Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо больше)
А так в нём нет ни unsigned, не int1 и int3, и даже ALTER TABLE ... ADD ... AFTER ...; нету.
Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка тоже нету!
Ох уж эти мамкины уделыватели по всем фронтам...
| | |
| |
| 3.56, Наме (?), 13:34, 06/12/2021 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо
> больше)
> А так в нём нет ни unsigned, не int1 и int3, и
> даже ALTER TABLE ... ADD ... AFTER ...; нету.
> Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка
> тоже нету!
> Ох уж эти мамкины уделыватели по всем фронтам...
Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), а Дельфин по умолчанию ISAM (транзакций и WAL-а нет, но бывают задачи где это всё лишняя нагрузка). Это как ткацкий станок сравнивать с вязальными спицами -- каждый хорош для своих задач.
| | |
| |
| 4.62, Ilya Indigo (ok), 13:50, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций),
Вы не поверите, InnoDB тоже!
> а Дельфин по умолчанию ISAM
MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где нужна быстрая вставка можно и MyISAM использовать в той же самой БД!
| | |
| |
| 5.65, Наме (?), 14:01, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций),
> Вы не поверите, InnoDB тоже!
>> а Дельфин по умолчанию ISAM
> MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где
> нужна быстрая вставка можно и MyISAM использовать в той же самой
> БД!
Это под вендой. Но Инно тоже Слону не конкурент. Совершенно разного масштаба явления.
| | |
| |
| |
| 7.76, Ilya Indigo (ok), 14:33, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.
Да уже по первому комментарию и так понятно что аноним совершенно не понимает о чём пишет, а когда его аргументы мною разбиты пишет снова глупость, не понятно зачем вообще упоминая оффтопик, и просит просто поверить ему.
| | |
| |
| 8.93, Наме (?), 15:57, 06/12/2021 [^] [^^] [^^^] [ответить] | –11 +/– | Ильюша, ты пишешь на пэхэпэ Эти всё сказано о твоим интеллектуальных способност... текст свёрнут, показать | | |
| |
| |
| 10.186, Наме (?), 10:42, 07/12/2021 [^] [^^] [^^^] [ответить] | –1 +/– | Я о том, что пэхэпёр вряд ли в свой профессиональной жизни плотно сталкивается с... текст свёрнут, показать | | |
|
|
|
|
|
|
| 4.85, vitalif (ok), 15:18, 06/12/2021 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Под какой виндой, что ты несёшь?
Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)
| | |
| |
| 5.94, Наме (?), 15:59, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Под какой виндой, что ты несёшь?
> Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC,
> причём что важно - там нет грёбаного вакуума)
Практически везде. Просто в силу того, что ISAM для многих задач достаточен.
| | |
| 5.95, Наме (?), 16:05, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
> Под какой виндой, что ты несёшь?
> Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC,
> причём что важно - там нет грёбаного вакуума)
Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?
| | |
| |
| 6.185, _hide_ (ok), 10:39, 07/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?
Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью операций. Пишем в лог, читаем из данных и лога (причем все проблемы синхронизации и доступности решает движок БД, разве не классно?). Когда не Hello World, а 300 клиентов пишут/читают единовременно из одного набора данных, такие вопросы вызывают лишь улыбку.
И да ISAM-кие движки всегда были ReadOnly after write? Или были какие-то решения для обхода ограничений?
| | |
| |
| 7.187, Наме (?), 10:47, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
> Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью
> операций. Пишем в лог, читаем из данных и лога (причем все
> проблемы синхронизации и доступности решает движок БД, разве не классно?).
Каких ещё блокировок? Вот есть у тебя ряд реализаций MVCC, одна хранит историю в виде исходных строк в том же месте, где они были до удаления/изменения, другая пишет, условно, диффы в другое место, а на прежнем месте городит сложную структуру из цепных ссылок, третья делает что-то среднее между первым и вторым -- какие-то удалённые строки держит на прежнем месте, какие-то выносит в отдельную помойку, а какие-то изменения просто хранит в виде инструкций в журнале изменений. Какой способ лучше?
| | |
| |
| 8.194, _hide_ (ok), 11:06, 07/12/2021 [^] [^^] [^^^] [ответить] | +/– | Мы скоро обсуждать будем ассемблерные вставки Кто это пишет дифы Никто никаких... большой текст свёрнут, показать | | |
| |
| 9.199, Наме (?), 11:33, 07/12/2021 [^] [^^] [^^^] [ответить] | +/– | Оракл, например, пишет диффы образно выражаясь, там что-то вроде инструкций р... текст свёрнут, показать | | |
|
|
|
|
| 5.103, Аноним (103), 16:48, 06/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это те же яйца даже не в профиль.
| | |
| |
| 6.109, Наме (?), 17:13, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
> Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это
> те же яйца даже не в профиль.
Нет, это и близко не одни и те же "яйца". Одна чистит БД от призраков и освобождает счётчик транзакций (изменений), другая проводит пересортировку таблиц.
| | |
| |
| 7.188, _hide_ (ok), 10:48, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> другая проводит пересортировку таблиц.
Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи имеет свою цену и одна из них -- большое количество мертвых данных) заполняется сортированным для чтения набором данных и пересчитанными индексами (после релокейта деток, приходится и индексы пересчитывать)
> освобождает счётчик транзакций (изменений)
В том контексте, которые используется мной, такие действия выполняются при коммите транзакции (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)
| | |
| |
| 8.197, Наме (?), 11:30, 07/12/2021 [^] [^^] [^^^] [ответить] | +/– | Ты не в курсе У Слона счётчик циркулярный, ещё и меридианный Уроборос этакий... большой текст свёрнут, показать | | |
|
| 7.192, Аноним (192), 10:56, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
А вот это в корне не так, если говорить о б-жественном InnoDB. InnoDB не поддерживает OPTIMIZE напрямую, вместо этого все данные из таблицы копируются во временную таблицу, которая потом замещает оригинальную.
| | |
|
| 6.136, Онаним (?), 20:58, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Если InnoDB не наполнять очень хитрым образом - необходимости в OPTIMIZE TABLE обычно не существует.
| | |
| |
| |
| 8.190, Онаним (?), 10:51, 07/12/2021 [^] [^^] [^^^] [ответить] | –1 +/– | Перепутали с постгрёй и вакуумом InnoDB - это не постгря, она умеет заполнять о... текст свёрнут, показать | | |
|
|
|
| 5.250, www2 (??), 07:30, 22/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)
А вакуум над ibdata1 не помешал бы. Полное резервное копирование с последующим восстановлением из резервной копии - так себе альтернатива для вакуума. Но тем, у кого полная резервная копия делается за полчаса, а перерыв в работе в несколько часов не особо критичен, MySQL пойдёт.
| | |
|
|
| 3.122, Catwoolfii (ok), 20:08, 06/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
 У мускула определенно есть некоторые плюсы в сравнении со слоном, но только не язык запросов. Такой огрызок еще поискать надо...
| | |
| |
| 4.124, Ilya Indigo (ok), 20:17, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
> У мускула определенно есть некоторые плюсы в сравнении со слоном, но только
> не язык запросов. Такой огрызок еще поискать надо...
Я хоть от одного мамкиного слонёнка конкретику услышу с примерами и пруфами, или только один глупый и необоснованный детский бред!?
| | |
|
| 3.182, fuggy (ok), 10:28, 07/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > нет ни unsigned, не int1 и int3
unsigned нет в SQL стандарте. int1 это для тех кто не умеет boolean. int3 вообще какая-то эзотерика, никому не нужная. smallint достаточно. Ну уж в количестве типов тягаться с PostgreSQL не стоит. Там есть array, intrange, daterange, xml, json, inet, геометрические типы. Даже банального uuid нет.
> ALTER TABLE ... ADD ... AFTER ...
В стандарте у колонок нету порядка. Да функция удобная, но без неё можно прожить.
Про CONSTRAINT CHECK ничего не хочешь сказать? Он как бы есть, но его нет.
И уж сравнивать по фичам MySQL не стоит. Подключаемые движки, это единственное что пока есть. Они хороши только для определённой нагрузки. Зато нет набора типов индексов, с помощью которых можно улучшить некоторые операции.
| | |
| |
| 4.191, Онаним (?), 10:53, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Зато есть отсутствие vacuum, которое автоматически улучшает куда больше, чем тот самый набор индексов. Кстати индексы по (даже не хранимым) вычисляемым полям в MariaDB давно можно делать, и поэтому ряд вещей таким способом и решается. Но соглашусь, маразм с отсутствием DESC индексов решён пока только в ванильной восьмёрке.
| | |
| |
| 5.216, fuggy (ok), 14:26, 07/12/2021 [^] [^^] [^^^] [ответить] | +1 +/– | Вакуум это лишь отложенное амортизированное время операции на вставку удаление, ... большой текст свёрнут, показать | | |
|
|
|
| 2.87, minonA (?), 15:27, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Так, на вскидку, а есть ли в PostgreSQL аналог MEMORY таблицы? Вообще проблема оптимизатора MySQL преувеличена. Да, в Postgres он умнее. Но и в MySQL можно добиться схожих результатов немного подкрутив. А если говорить о простых запросах, что наиболее частый юзер-кейс, MySQL вообще ничем не хуже.
| | |
| |
| 3.102, AleksK (ok), 16:45, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я сужу по тому как работал мой проект на рельсах. Загрузка базы в проект из yaml ну просто в разы быстрее при использовании postgres, да и отзывчивость в общем получше. Я не проводил специальных тестов просто общие впечатления от работы на одном и на другом.
| | |
|
|
| 1.10, flexagoon (ok), 11:40, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –13 +/– |
 > MySQL сильно устарел и не эффективен, при том, что большинство пользователей и разработчиков считают, что всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёд
Они тут слово "My" нечаянно перед "SQL" добавили
| | |
| |
| |
| |
| 4.251, www2 (??), 07:42, 22/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
На SQL по крайней мере стандарт есть и даже те, кто его не придерживается, изображают что-то более-менее одно и то же.
Оптимизатор SQL-запросов способен учитывать статистику данных в таблицах, наличие индексов по нужным полям и налету может изменить порядок соединения таблиц. При изменении данных в базе SQL проверяются ограничения, ссылочная целостность. В SQL есть полноценные транзакции с возможностью откатиться до промежуточной контрольной точки.
А вот на NoSQL никаких стандартов нет, каждый выдумывает что-то своё. И похоже всё это на закат солнца вручную.
| | |
| |
| 5.254, Всем Анонимам Аноним (?), 15:06, 28/01/2022 [^] [^^] [^^^] [ответить]
| +/– |
Все зависит от цели. Когда много данных и нужна скорость, но целостность - не проблема, то почему бы нет.
Хотя я согласен, Гугл даже строит новую базу себе типа SQL, называется Spanner. Вначале думали да, все проблемы можно возложить на код, но потом пришли к выводу, что проще чтобы база данных этим все-таки занималась.
| | |
|
|
|
|
| 1.12, Аноним (12), 11:42, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –17 +/– |
Использовал и то и другое, особой разницы не заметил. Для малых и средних сайтов MySQL - идеальное решение, поскольку там лучше дока и больше туторов. А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами и оптимизациями банально не потянет.
| | |
| |
| 2.16, Аноним (16), 11:55, 06/12/2021 [^] [^^] [^^^] [ответить]
| +6 +/– |
Не знаю чем там сильно отличаются туториалы для малых и средних сайтов, так как для малых и средних сайтов база всё равно считается детской по структуре.
А вот для более серьёзных проектов (веб/десктоп, АРМ, и тд) всё таки более гибкая в проектировании PostgreSQL я считаю. Логику делать очень удобно. И как раз таки нормальная дока по нему в целом.
| | |
| 2.33, Аноним (33), 12:26, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Вывод ты делаешь малые и средние сайты. Больше из твоего комментария нечего почерпнуть.
| | |
| 2.148, arisu (ok), 21:58, 06/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами
> и оптимизациями банально не потянет.
потянет и это. просто надо применить Секретную Оптимизацию: выгнать на мороз тебя и тебе подобных «специалистов».
| | |
|
| 1.13, Аноним (-), 11:48, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Ну всё, мария не торт, мускуль не торт, постгрес не торт, и раст нас не спасёт, потому что там тоже все paзocpaлиcь.
| | |
| |
| 2.29, Rev (?), 12:21, 06/12/2021 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> там тоже все paзocpaлиcь
Кто "все"? Модераторы CoC? Ах, увольте...
| | |
| |
| 3.81, topin89 (ok), 14:51, 06/12/2021 [^] [^^] [^^^] [ответить] | +2 +/– |  Если бы всё было так просто Один из ключевых разработчиков забросил Rust Wasm, ... большой текст свёрнут, показать | | |
| |
| 4.113, Kuromi (ok), 17:56, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Отличная ссылочка. Читается на одном дыхании как один большой анекдот. Только это все реальность.
Хотя если честно я не понимаю что мешает Rust Core Team обратиться к админам гитхаба и попросить передать им права, в конце концов речь идет не о группе анонимов из даркнета, а официально существующей организации.
| | |
|
|
| |
| |
| 4.73, funny.falcon (?), 14:28, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Очень зря. MongoDB вполне себе надёжная и удобная в эксплуатации база в наши дни. Я имею в виду эксплуатацию с точки зрения администрирования.
Правда, консистентный бэкап шардированного кластера сделали платной фичей. Его можно повторить руками, но минимум несколько месяцев интенсивной разработки обойдётся.
Но у кого он вообще есть - бесплатный консистентный бэкап шардированного кластера? Знаю, у TiDB. У кого ещё?
| | |
|
|
|
| 1.19, Простоник (ok), 11:58, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит.
| | |
| |
| 2.30, Аноним (33), 12:24, 06/12/2021 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ты ведь сейчас вордпресс имел ввиде и что УГ, да? И правильно сделал.
| | |
| |
| 3.38, Простоник (ok), 12:39, 06/12/2021 [^] [^^] [^^^] [ответить]
| –4 +/– |
(Зевая) Я не знаю что там хранит вордпресс и в каком виде, но хранить в подобной базе большое количество таблиц особенно со сложной структурой и сложными запросами я бы не стал. А так пяток таблиц для блога подойдёт.
| | |
|
| |
| 3.171, ddd2 (?), 06:36, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
у них свое ответвление MySQL с 2008-2009 года. Там от родного MySQL только названия.
| | |
| |
| 4.172, Простоник (ok), 07:44, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Админ у них просто героический. Для hi load эта штука не имеет необходимых механизмов. Амбразуры, похоже, приходится закрывать собственным телом(пристройкой сарайчиков и землянок).
| | |
|
|
| 2.134, Онаним (?), 20:56, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт.
Окей.
| | |
| |
| 3.149, arisu (ok), 22:01, 06/12/2021 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт.
> Окей.
вообще-то так и есть. но ты этого всё равно не поймёшь, что очевидно по глупости твоего комментария.
| | |
|
| 2.224, anonymous (??), 12:23, 08/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит.
Небольших сайтов вроде FB.com и pinterest
| | |
|
| 1.20, kai3341 (ok), 12:00, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ. Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует. Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это топовый OLTP движок
Претензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования. То есть если вы индексируете, например, новости, которые есть временной ряд -- поиск с указанием временных рамок будет крайне грустненьким
PS: У постгреса другие сильные стороны. Например, бесплатный rollback
| | |
| |
| 2.57, Ilya Indigo (ok), 13:34, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Реализация fulltext очень грустная
Ну так если нужно нормальный, то для этого Sphinx есть.
А то что есть это просто что бы было кому лень со сфинксом заморачиваться.
| | |
| 2.58, Наме (?), 13:46, 06/12/2021 [^] [^^] [^^^] [ответить] | +1 +/– | Попутал ты всё Какой кластерный первичный ключ Это в МС Сиквеле типично отно... большой текст свёрнут, показать | | |
| |
| |
| 4.96, Наме (?), 16:10, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> А можно ссылочки на развал БД при краше?
Разверни. Запусти длительную транзакцию, не завершая её выруби питание. Т.к. данные UNDO скорее всего в полном объёме не попадут в журнал, то при обратном проигрывании при восстановлении получить несогласованную БД. Тут должны, конечно, звёзды сойтись. Чтобы грязные блоки уже попали на диск, но при этом вектор UNDO ещё нет. Но во "взрослых" СУБД это принципиально невозможно, а в Инно вполне под рабочей нагрузкой. Хотя это практически, объективно говоря, маловероятно, но при случае проблем при восстановлении добавит.
| | |
| |
| 5.119, nik (??), 19:57, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
че за бред ?? -- все изменения в данных и в том же UNDO сохраняются в REDO, и пофиг длинная там транзакция или короткая, при сбросе питания все откатится до последнего COMMIT, а то что "не успело" -- вернется в пред. состояние из UNDO.
| | |
| |
| 6.141, Мимо_проходил (?), 21:09, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
> че за бред ?? -- все изменения в данных и в том
> же UNDO сохраняются в REDO, и пофиг длинная там транзакция или
> короткая, при сбросе питания все откатится до последнего COMMIT, а то
> что "не успело" -- вернется в пред. состояние из UNDO.
Нет, это не так. Возможны состояния, когда UNDO не оказалось в REDO, а изменённые блоки уже на диске.
| | |
|
| 5.133, Онаним (?), 20:55, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Бред.
Ну или эксплуатация на системе, не умеющей в write barrier - там что угодно развалится, не только InnoDB.
| | |
| |
| 6.139, Мимо_проходил (?), 21:07, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
> Бред.
> Ну или эксплуатация на системе, не умеющей в write barrier - там
> что угодно развалится, не только InnoDB.
Словья-то какие воспроизводим. Ещё бы знали, что это значит )))) Write barrier тут вообще не причём. Причём тут то, что Inno не обеспечивает WAL для UNDO. Вот и всё. Сделано это из соображений, да, скорости. И, в общем, имеет право на жизнь.
| | |
| |
| 7.140, Онаним (?), 21:08, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Короче я не знаю, как ты умудрился InnoDB развалить - у меня за долгие годы не получилось.
| | |
| |
| 8.195, 1 (??), 11:21, 07/12/2021 [^] [^^] [^^^] [ответить] | +/– | У тебя просто не было длинных транзакций А так разваливается и при резком вы... текст свёрнут, показать | | |
|
| 7.142, Онаним (?), 21:10, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
И что значит при чём тут WB.
Когда двиг выставляет fsync()/fdatasync()/sync_file_range(), он ожидает, что на диске к моменту завершения будет всё, что он отписал, и заказал. Если WB нет - с энной вероятностью хрен оно будет на диске вовремя, и рандомное выключение приведёт к интересному.
| | |
| 7.143, Онаним (?), 21:20, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Ну и да, какой WAL для UNDO вы вообще собрались писать, если к моменту коммита в REDO данные только в REDO. Далее его флашим в таблицу как придётся, когда по нагрузке посвободнее например, даже если что-то отвалится, делаем рефлаш. Двойная нагрузка на флаш, ещё и с чтением из REDO, если из буфера вылетело, выйдет только когда REDO заполнен.
Это две разные парадигмы - либо пишем в REDO и флашим в таблицу потом, либо сразу пишем в таблицу и далее начинаются пляски с UNDO: мы либо переносим, и тогда получаем двойную нагрузку в момент транзакции, либо как в постгресном, пишем CoW'ом, и тогда надо вакуумить. Если у нас UNDO есть, REDO уже не нужен.
| | |
| 7.144, Онаним (?), 21:26, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Могу ещё подсказать как без WB редо развалить.
Всё не просто, а очень просто: мы флашим редо, выставляем синк на таблицу, выставляем синк на поинтеры редо. Если таблица на диск не попала, а поинтеры внезапно попали - имеем лютый 3.14ц, в таблице старые данные, в редо уже ничего.
С андо попроще, с андо корова конечно решает, но зато корову вакуумить надо регулярно.
| | |
|
|
|
|
| 3.86, penetrator (?), 15:24, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень очень давно (задолго до появления самого Azure)
| | |
| |
| 4.98, Наме (?), 16:12, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
> очень давно (задолго до появления самого Azure)
Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
| | |
| |
| 5.101, penetrator (?), 16:45, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень
>> очень давно (задолго до появления самого Azure)
> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
некластерный, heap или как хочешь еще, и он там есть и есть очень давно
PK в MSSQL может быть 2 типов
с пробуждением
| | |
| |
| 6.105, Наме (?), 16:59, 06/12/2021 [^] [^^] [^^^] [ответить] | –1 +/– | Heap это, пардон, куча Т е когда данные хранятся вообще вне всякой упорядоченн... большой текст свёрнут, показать | | |
| |
| 7.152, penetrator (?), 22:53, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sq
Heaps are tables without a clustered index.
Я вообще не собирался лезть в детали, я про то что в MSSQL ЕСТЬ КУЧИ.
Это онли про "Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча"
Куча вполне себе возможна, доступна и используется в MSSQL. Это то, что я имел ввиду.
Куча возможна если нет ниодного кластерного индекса, которым обычно и является первичный ключ (первый и часто единственный кандидат).
Никакие нюансы терминологии меня в душе не ебали в тот момент.
Я только вернул кучи назад в MSSQL Server! С этим же все согласны? Ну вот и отлично.
| | |
| |
| 8.202, Наме (?), 11:43, 07/12/2021 [^] [^^] [^^^] [ответить] | +/– | Не серчай Вокруг этой темы перебор всякой терминологии У многих в результате к... текст свёрнут, показать | | |
|
|
| 6.107, Наме (?), 17:01, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> PK в MSSQL может быть 2 типов
Как бы, PK это не индекс, а Constrain -- ограничение первичного ключа. Который реализуется, под капотом, созданием уникального кластерного уже Индекса, если явно не заказать создавать не кластерный индекс, а дополнительный.
| | |
| 6.108, Наме (?), 17:07, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
> некластерный, heap или как хочешь еще, и он там есть и есть
> очень давно
> PK в MSSQL может быть 2 типов
Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK же (Primary Key) это одно из видов Ограничений, которое реализуется либо тем, что все данные отношения помещаются в структуру индекса, либо тем, что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой на листах хранятся данные индексного ключа и ссылки на страницы кучи, где хранится оригинальная индексируемая строка.
| | |
| |
| 7.110, Наме (?), 17:18, 06/12/2021 [^] [^^] [^^^] [ответить] | +/– | Хотя, малыши, я тут несколько ошибся Когда заказываешь PK к существующему уже о... большой текст свёрнут, показать | | |
|
|
|
|
| |
| 4.206, Наме (?), 12:15, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
>> Попутал ты всё. Какой "кластерный первичный ключ"?
> https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
> Each InnoDB table has a special index called the clustered index that
> stores row data. Typically, the clustered index is synonymous with the
> primary key.
> Не попутал.
Кластерный индекс это... хм... индекс. А Первичный ключ это... ограничение. Просто в силу того, что в МС Сиквеле (и в Инно) зачастую разраб при определении отношения сразу пишет требование ограничения PK (причём, по умолчанию оно реализуется именно кластерным индексом), то ему и невдомёк, что Ограничение и Индекс это не одно и тоже. Совсем.
| | |
| |
| 5.210, kai3341 (ok), 13:12, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Each InnoDB table has a special index called the clustered index
Я настоятельно рекомендую использовать терминологию официальной документации, а не вашу собственную
| | |
| |
| 6.211, Наме (?), 13:35, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично.
Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
| | |
| 6.212, Наме (?), 13:35, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично.
Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
| | |
| 6.235, Онаним (?), 09:19, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
У пользователей MSSQL проблемы с тем, что они умудряются мешать индексы с констрейнтами, при этом их механически разделяя :D
| | |
|
|
|
|
| |
| 3.184, kai3341 (ok), 10:38, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
Ознакомьтесь с документацией. Между optimize table и autovacuum есть огромная разница. Начиная с того, что optimize table -- это опция, которую можно не запускать никогда, а вот autovacuum отключать очень не рекомендуется
Ещё раз -- это разница между демоном, который в норме должен работать постоянно, и опцией, которую можно годами не запускать
| | |
| |
| 4.233, Аноним (232), 05:40, 09/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Зависит от типа нагрузки, с одной без optimize table у вас диск переполнится, а с другой можно и автоваккум отключить.
| | |
| |
| 5.236, Онаним (?), 09:21, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Каким образом "переполнится диск" без optimize table, если innodb прекрасно умеет писать данные в освободившиеся страницы, не потрудитесь объяснить?
Нет, есть там пара очень специфичных случаев, но вы их вряд ли приведёте, с ними мало кто сталкивается.
| | |
|
|
|
| 2.68, Аноним (68), 14:18, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> необходимость богомерзкого autovacuum отсутствует
Богомерзкое - это писать логи. А автовакуум это красота.
| | |
| |
| 3.237, Онаним (?), 09:26, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
У вас MVCC уже без лога работает?
И даже с индексами?
На самом деле нет. Постгря всё так же прекрасно пишет redo log, просто его назвали wal.
| | |
|
|
| 1.25, Аноним (33), 12:17, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Местные Аноноимы опускают MySQL уже 20-ый год. Но только сейчас до одного из разработчиков MySQL дошло что он занимается фигнёй.
| | |
| |
| 2.36, Аноним (-), 12:34, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если копры его забросят - получится отличный и стабильный продукт. Надеемся что не начнут хотеть переписать на раст или что-то.
| | |
| |
| |
| 4.46, Аноним (-), 13:14, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Пральна, раздать все копрам, и сосать лапу. Иначе же стогнация, нелицензионность и прочая протухаемость.
| | |
|
|
| 2.45, th3m3 (ok), 13:11, 06/12/2021 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Наконец-то мы были услышаны! Ждём осознания в станах Вордпресса, пехепешников.
| | |
| |
| 3.74, 123 (??), 14:29, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
В станах "Вордпресса" давно предлагают использовать MariaDB.
| | |
|
|
| 1.27, devkornev (ok), 12:20, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 С новыми проектами - ок, выбор за Postgres. Но что делать, где уже MySQL. Обновление с 5 на 8 выливается в существенное замедление.
| | |
| |
| 2.50, Аноним (33), 13:22, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Масштабироваться причем вертикально. Горизонтально не каждый сможет.
| | |
|
| |
| |
| 3.131, Онаним (?), 20:52, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Тут два вопроса:
1) Зачем конкретно? В большинстве случаев вообще не требуется. Единственное исключение - компактинг избыточно разлапистого индекса.
2) OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.
| | |
| 3.132, Онаним (?), 20:53, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Точнее второе даже не вопрос. Онлайновая операция это ныне на InnoDB, которая допускает DML во время выполнения.
| | |
|
|
| 1.35, Аноним (-), 12:32, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёд
Ну ушли себе и ушли, это их проблемы.
| | |
| 1.39, An (??), 12:50, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил на себе адсенс гугла, метрику и директ яндекса. А? Это говорит о том, что вы, господа - рукожопы. И не умеете готовить мускул.
| | |
| |
| 2.43, Аноним (41), 13:10, 06/12/2021 [^] [^^] [^^^] [ответить]
| +4 +/– |
На маленьком проекте использовал гугл адсенс. Подключил скрипт JS и всё. Базу не использовал вообще. Путь к скрипту лежал в файлике. Значит можно мускуль заменить на файлик.
| | |
| 2.48, Аноним (48), 13:15, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Про MySQL в Google Adsense - это миф, никогда он там не использовался. Вы видимо с Facebook путайте.
| | |
| 2.49, Аноним (33), 13:19, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
В mail.ru используют джангу вместе с MySQL и им норм. Но это совершенно не значит что так надо делать всем.
| | |
| 2.61, Наме (?), 13:49, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
> А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил
> на себе адсенс гугла, метрику и директ яндекса. А? Это говорит
> о том, что вы, господа - рукожопы. И не умеете готовить
> мускул.
Вряд ли. ISAM хорош, когда надо много писать в хвост и не нужны транзакции. Например, в какой-нибудь системе не слишком ответственного логирования, где источник сообщений сам имеет надёжное хранилище.
| | |
| |
| 3.130, Онаним (?), 20:47, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
На самом деле уже давно нет.
И даже для логов нет. Потому что при обрыве записи эти гигасы вылетят на LOCK+REPAIR, и будет прелесть.
InnoDB очень шустр ныне. Годится и для write-mostly в т.ч. Объёмы итоговые только негуманные, но со сжатием терпимо.
| | |
|
| 2.67, Аноним (67), 14:08, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
+1
Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост.
Или делать шардинг.
Все что касается административной части то у слоника все печально.
| | |
| |
| 3.82, Наме (?), 14:53, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
> +1
> Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост.
> Или делать шардинг.
> Все что касается административной части то у слоника все печально.
Ну Слоника со всем всё прекрасно. Ещё бы кластеризацию запилили и вообще было бы прекрасно.
| | |
| |
| 4.84, Аноним (67), 15:02, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без даунтайма
| | |
| |
| 5.99, Наме (?), 16:16, 06/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без
> даунтайма
А в чём сложность? Ну не RAC, конечно, но вполне можно довести до приемлемого уровня.
| | |
| |
| 6.129, Онаним (?), 20:46, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Можно, вопрос какой ценой.
А в случае мускула всё это очень легко и ненавязчиво.
| | |
| |
| 7.163, Аноним (67), 00:45, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Именно. Или пусть расскажет как будет восстанавливать X траназакций котоые удалили спустя 10-15 секунд PITR.
Хотя что такое 200 потерянных транзакций и кому это может быть интересно.
| | |
|
|
|
| |
| |
| 6.123, Alexander (ok), 20:14, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/
> Ну это Мария. А это всё тот же ISAM, только навороченный. Но
> я не пробовал, ничего сказать не могу.
Вы что-то путаете:
---
Конечно, помимо достоинств у кластера Galera есть и ограничения (перевод фрагмента с официального сайта MariaDB):
Репликация поддерживается только для таблиц в формате InnoDB;
---
Да, я тоже не пробовал :)
| | |
| 6.239, Онаним (?), 09:32, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Какой ISAM, о чём вы. InnoDB к ISAM вообще отношения не имеет, это продукт Innobase, причём эту компаху Oracle купила задолго до санок с MySQL.
| | |
|
|
|
|
|
| |
| 2.59, Аноним (-), 13:47, 06/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
Действительно, когда нужен скуль почему же не взять монгу, хмм.
| | |
|
| 1.63, Аноним (63), 13:51, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Дык мускуль и задуман как бесплатная поделка для студентов. Никто никогда и не говорил, что он пригоден для коммерческих продуктов. Так что я не знаю, кого он там пугает.
| | |
| |
| 2.78, ыы (?), 14:41, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
очень любопытная мысль... не хотите ее развить?
Расскажите нам для чего был задуман PHP, Линукс, автомобиль, колесо...
| | |
| |
| 3.208, InuYasha (??), 12:40, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
вот как рыз вы в кучу мешаете носки с помидорами. PHP был задуман для добавления динамики в хоумпаги, а большой спрос и низкая квалификация родили монстра.
| | |
| |
| 4.229, ыы (?), 22:15, 08/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>а большой спрос и низкая квалификация
кто же такой умный задумывал его для хоумпегов которые будут верстаться при низком спросе и высокой квалификации?
какие такие хоумпеги имелись в виду?
| | |
| 4.240, Онаним (?), 09:33, 10/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Интернет задумывался как сеть для оборонного ведомства, а 640кб в своё время хватало всем. Windows 1.0 тоже был очередным унылым файловым менеджером для DOS.
| | |
| |
| 5.241, Онаним (?), 09:34, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
(вещи, которые оказались удобны и востребованы - имеют свойство перерастать себя)
| | |
| 5.242, Онаним (?), 09:37, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Freax тоже когда-то был личной поделкой под себя любимого, просто чтобы миних на 386 не пользовать.
| | |
|
|
|
|
| 1.71, ыы (?), 14:22, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> не выделяет должных ресурсов, что мешает поддержанию его в виде конкурентоспособного продукта.
Опенсорс в полный рост... А как же разработка сообществом? Где миллион волонтеров пишущих код оптимизатора?
| | |
| |
| 2.150, arisu (ok), 22:10, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Где миллион волонтеров
давно используют постгрес и довольны. а кто в постгрес нормально не смог… ну, я не уверен, что это хороший вариант для MySQL.
| | |
|
| |
| 2.91, Простоник (ok), 15:53, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Хороший вопрос. Ответ зависит от того, сколько этот оптимизатор будет стоить.
| | |
| 2.151, arisu (ok), 22:12, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А всем ли нужен мощный оптимизатор запросов?
да. потому что сделать из мощного хреновый просто, а вот наоборот — очень сложно.
| | |
|
| 1.111, Аноним (111), 17:27, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"но в общем виде работа оценивается как доведение его до уровня технологий начала 2000-х годов"
И вот что ему не нравится. Технологию (пусть и старую) ДОВОДЯТ ДО УМА! А что постгресс? Конфетка уже?
| | |
| 1.114, bsdun (?), 18:42, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А что никто не говорит про Group Replication в MySQL из каропки, которой в PostgreSQL и в помине нет. Чёт не догоняю чем она отстаёт...
| | |
| 1.118, Имя (?), 19:31, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Вот когда постгрес предложит мне мультимастер из коробки, встроенный колоночный движок и миллион приблуд вокруг потому что протокол мускуля знают все сто лет, тогда я подумаю слезть с марии.
Всему свое, нет серебрянной пули (ну конечно если вы разработкой заняты а не чтением блогов).
| | |
| |
| 2.120, leap42 (ok), 19:59, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
 >> ...когда постгрес предложит мне мультимастер из коробки...
Опять 25... Зачем нужен мультимастер? Почти любая СУБД тормозит при записи на диск. Если у вас есть другой мастер, то с ним надо реплицироваться. Данные второго мастера тож надо писать другими словами. Производительность НЕ увеличивается. Это работало только с MySQL который всё тянул на одном(!) ядре процессора и иногда упирался в него. Убогий костыль для масштабирования по процу. Postgres уже лет 15 умеет в многоядерность, ему этот бред ни к чему.
| | |
| |
| 3.128, Онаним (?), 20:44, 06/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций.
А для бОльших гарантий есть синхронный мультимастер, Galera Cluster называется.
| | |
| |
| 4.138, ыы (?), 21:01, 06/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Это про возможность продолжить писать в условиях полного отказа одного из мастеров
В самом деле? Кто бы мог подумать ...
На самом деле все транзакции писавшиеся на отказавшем мастере откатываются... и все что не дошло до другого мастера тоже откатывается. Вы же не зафиксируете половину атомарной записи, правда? :)
Поэтому с точки зрения "продолжать писать при отказе" - мультимастер ничем не отличается от обычного переключения слэйва на праймори...
| | |
| |
| 5.145, Онаним (?), 21:41, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Э-э-э, вы точно себе представляете, как репликация работает?
Я вижу, что нет.
| | |
| |
| 6.176, funny.falcon (?), 08:35, 07/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Какая репликация? Синхронная? Асинхронная? Синхронная с кворумом? На протоколе консенсуса?
| | |
|
| 5.146, Онаним (?), 21:47, 06/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Ну и я же не зря написал: с потерей части транзакций. Если потеря части данных не вызывает проблем. Для всякой негарантированной статистики - более чем.
Если у нас нет строгих требований к упорядоченности - мы ещё и на любой мастер писать можем, да, будет лаг синхронизации, но см. в начало строчки.
Если нам нужен мульти-мастер с синхронностью и откатом - берём галеру. Там да, не завершённая транзакция откатывается со всех узлов. Но при этом нам не нужно ничего "переключать" - как только транзакция упавшего мастера откатится, следующие будут выполнены. Более того, мы можем на любой мастер писать.
| | |
| |
| 6.213, Наме (?), 13:37, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Если нужен "мультимастер", то берём Oracle RAC, а БД размещаем поверх ceph.
| | |
|
|
| 4.173, leap42 (ok), 08:06, 07/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>> Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций.
Вы не слушайте того кто вам такое говорит, он вообще не шарит. Когда primary отказывает, ближайший standby становится мастером сам. Всё. Почему это лучше мультимастера? - Очень легко избежать split brain. С асинхронным мультимастером избежать split brain вообще не всегда возможно - вопрос только "когда". Синхронный мультимастер ставит на колени производительность при географическом удалении нод в 100%, и почти всегда даже если они рядом.
| | |
| |
| 5.177, funny.falcon (?), 08:41, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Согласен на 99.99%
Мультимастер действительно более живуч. Но действительно тормознее.
Практически ни кому живучесть мультимастера не нужна. Время переключения реплики - обычно меньше 1 минуты (чаше всего, 10-20 секунд). Пять переключений в год - это доступность 99.999%. Этого достаточно даже для маркетплейсов и банков (хоть они и заявляют шесть девяток, но рады и пяти девяткам).
| | |
| |
| 6.214, Наме (?), 13:39, 07/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
Наоборот мульти-мастер это про производительность. Просто единственный реализованный нормальный мультимастер это RAC, где энное кол-во экземпляров работают с одним набором файлов данных (которые сами могут быть пространственно размазаны поверх сетевой фс). А галера эта муть какая-то.
| | |
|
|
|
|
|
| 1.125, Аноним (125), 20:35, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 GOOGLE vs ORACLE
Мужик-же просто отрабатывает подъемные у нового (старого) работодателя.
Все, увы, банально и старо, как мир. :)
| | |
| 1.127, Онаним (?), 20:43, 06/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Што, мужику отказали в возможности безальтернативный VACUUM в MySQL добавить? Так не приживётся он там, без него хорошо.
| | |
| 1.160, Фан (?), 00:04, 07/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
MySQL будучи карманной игрушкой Oracle по определению не может быть конкурентноспособной РСУБД, по причини наличия у Oracle своей собственной РСУБД
Слон же не принадлежит никому и поэтому искуственных палок в колеса ему не вставляют, есть еще Firebird, но это классическая РСУБД без новомодных приблуд, к слову очень хорошая
| | |
| |
| 2.179, Аноньимъ (ok), 09:38, 07/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
А натуральные вставляют?
Должен ли велик быть обязательно чьим-то чтобы вставлять ему палки в колёса?
| | |
| 2.183, Старший аноним (?), 10:31, 07/12/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
У вас какой уровень IQ, вьюноша?
Oracle взял свистоподелку и слепил из нее нормальный продукт.
Но если изначально были родовые травмы, то от них очень трудно избавиться.
| | |
| |
| 3.193, ыы (?), 10:57, 07/12/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Oracle взял свистоподелку и слепил из нее нормальный продукт.
Oracle купил (не взял, а именно купил) за много много долларооов, систему которая в тот момент уже надежно работала на половине сайтов в инете.
После продажи, автор, сделал крутой финт ушами- он потребовал чтобы Oracle вернула mysql сообществу.. и когда оракл покрутил пальцем у виска - автор сделал форк...
с тех пор так все и идет- оракл делает СО СВОИМ mysql то что считает нужным, а сообщество периодически недовольно ропщет недовольное СВОИМ mysql...
| | |
| |
| 4.198, ыы (?), 11:30, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку...
| | |
| |
| 5.205, arisu (ok), 12:08, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку...
не надо. там от продукта жизнедеятельности монти осталось примерно столько же, сколько в их компиляторе php от оригинального php.
| | |
|
|
| 3.225, Фан (?), 20:55, 08/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
В чем смысл коммерческой корпорации Oracle вкладывать в MySQL в ущерб своей Oracle? Или Oracle Corporation уж стал Oracle Foundation? И не разрабатывает MySQL по остаточном признаку
| | |
| |
| 4.230, ыы (?), 22:18, 08/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Мускул ниразу не конкурент ораклу. Совершенно разные целевые сегменты...
мускулем они закрывают нишу... и делают совершенно правильно.
| | |
| 4.252, www2 (??), 13:12, 23/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Версий много и все они могут быть правдивы как по отдельности, так и вместе:
- диверсифицируют риски,
- расширяют количество потенциальных клиентов,
- предоставляют полный сервис по решению проблем клиента в комплексе, а не ограничиваются задачей впарить один конкретный продукт всем подряд.
| | |
|
|
|
| 1.162, Аноним (162), 00:33, 07/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Выглядит как чувак не смог (занимался оптимизацией, которая по итогу оказалась на уровне 2000-х), ему сказали "и за что тебе платить?", он обидился, свалил и решил нагадить под дверь ораклам.
| | |
| 1.170, Виктор (??), 05:45, 07/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Используйте инструменты по назначению, да не везде будут фишки остальных баз. Но свои функции для сайтов вполне справляется, если ты не фирма гигант конечно же!
| | |
| 1.200, 1 (??), 11:41, 07/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не вижу комментариев - зачем они нужны, когда есть SQLite ?
| | |
| |
| 2.203, ыы (?), 11:47, 07/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Это настолько самособой разумеется, что даже холиварить повода нет...
| | |
|
| 1.209, InuYasha (??), 12:45, 07/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Oracle не выделяет должных ресурсов
Смешно. Не то чтобы они купили май для захоронения, но вообще Oracle скатывает всё в помойную яму, какапывая тоннами лицензий, контрактов, подписок и поливая вендорлоками.
| | |
| |
| 2.231, ыы (?), 22:19, 08/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
mssql на линухе уже научилась через шаред мемори работать?
| | |
| 2.243, Онаним (?), 09:40, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
В MSSQL особо убивает стохастика оптимизатора - финальный план запроса может меняться 100500 раз при просто последовательном выполнении одного и того же запроса. Мало того без профайлера не разгребёшь, где засада, так ещё и каждый запуск выливается в разные планы, и результаты профайлера не бьются друг с другом. Наши виндодевелоперы с ним трахаются с завидной регулярностью.
| | |
| |
| 3.244, arisu (ok), 11:02, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
как удивительно: сервер видит повторяющиеся паттерны — и оптимизирует под них. вот же гад какой, а!
| | |
| |
| 4.245, Онаним (?), 12:09, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ды не, если бы он стабильно делал, а там именно стохастика где-то, потому что планы таки повторяются, но в ряде случаев для этого надо, чтобы фаза луны сошлась. По незадаче, это как раз те случаи, где запрос здоровый, и есть какая-то проблема... которую потрекать даже с профайлером трудно, поскольку стохастика не даёт предсказать результат изменений в самом запросе.
| | |
| |
| 5.246, arisu (ok), 12:18, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
ну. пробует разные планы, ведёт статистику. в принципе, нормальный метод оптимизации — для реальных нагрузок, где несколько плохих планов нивелируются последующими выигрышами. вполне логично, что при таких раскладах бенчмарки имеют такой же смысл, как и любая другая ИБД.
| | |
| |
| 6.247, Онаним (?), 12:31, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ды там дело не в бенчмарке. Там проблема проблему трекнуть.
Оно на половине его стохастики допустим где-то костыляется, и вместо 0.01 сек выдаёт 2-3 сек на том же запросе, при _отсутствии_ параллельных запросов - в идеальном сферическом тесте в вакууме. При этом план совершенно другой, чем вызвано - никто не объясняет, как фиксить - непонятно.
| | |
| |
| 7.248, Онаним (?), 12:33, 10/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
(точнее понятно, и уже зафиксили) Разбили запрос на три и объединение через хранимку, в итоге вместо 0.01-2.6 стали почти стабильные 0.07-0.14, плохо, но лучше, чем вот та задница.
| | |
|
|
|
|
|
|
|
