Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL, opennews (??), 06-Дек-21, (0) [смотреть все] всегда использовал слоника заместо вот этого вот детища оракула, Аноним (1), 11:21 , 06-Дек-21, (1) –1 // Тот, кто так говорит, явно не мог его использовать 12 лет назад Значит использ, _hide_ (ok), 11:25 , 06-Дек-21, (4) +21 // с 2011, мистер Холмс, сэр, Аноним (1), 11:51 , 06-Дек-21, (14) +9 Я аж в голос с этого клоуна , проект однодневка (?), 14:49 , 06-Дек-21, (80) –5 бред, помню, даже в 2000-м году делал пару поделок на постгресе и уже тогда вита, лютый жабби__ (?), 15:31 , 06-Дек-21, (90) –5 // Всё зависит от того, чем Вы занимаетесь При обновлении 10-15 ГБ с ПГ Вы упирает, _hide_ (ok), 17:00 , 06-Дек-21, (106) +5 Работал недавно на проекте, которому уже почти 10 лет и который является топ 1 р, Степан (?), 02:03 , 07-Дек-21, (164) Чат для котегафф , _ (??), 08:15 , 07-Дек-21, (174) +4 В переводе с опеннетского это видимо означает, что нужна команда высококлассных , Аноньимъ (ok), 02:49 , 07-Дек-21, (165) В 2004 делал проект биллинга провайдера на постгресе, michelle (??), 20:40 , 06-Дек-21, (126) // Когда Вадиму Михееву работал в соседнем здании и был с ним знаком в 1995 году , cadmi (?), 13:46 , 07-Дек-21, (215) +1 Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с 8-й в, Аноним (157), 23:26 , 06-Дек-21, (157) +1 // Чувствуется какая-то связь между этими наблюдениями , YetAnotherOnanym (ok), 23:36 , 06-Дек-21, (158) Это Вы про скороть чтения на одинаковом железе или сравниваете корпоративный сер, _hide_ (ok), 00:32 , 07-Дек-21, (161) +1 при этом вполне синтаксически корректные конструкции в запросе MySQL вполне мож, моррут (?), 09:44 , 07-Дек-21, (180) Вот откуда берется это про нужно настраивать Там все основные настройки в кон, Анонимус314 (?), 21:58 , 08-Дек-21, (228) С Postgre95 , анон ессно (?), 15:54 , 07-Дек-21, (222) // Postgres95, Аноним (232), 05:30 , 09-Дек-21, (232) Ничего вы, батенька, не понимаете в залепухах для прачечных , Ян Злобин (ok), 11:57 , 06-Дек-21, (18) +1 Зелёного , Аноним (51), 13:25 , 06-Дек-21, (51) +9 Вот и выросло поколение Хоть википедию бы почитали бы, Аноним (117), 19:14 , 06-Дек-21, (117) +11 Вот кстати тоже не понимаю зачем нужен MySQL если есть Postgres, который уделыва, AleksK (ok), 11:22 , 06-Дек-21, (2) +7   // По каким параметрам А мне казалось, что применение PG -- это очень взвешенное и , _hide_ (ok), 11:27 , 06-Дек-21, (5) +7   Не по всем Я, как любитель PostgreSQL, ответственно заявляю Причины, по которым, funny.falcon (?), 11:30 , 06-Дек-21, (6) +8   // Если они изначально делали все под MySQL, то не удивительно А так по моему опыт, AleksK (ok), 11:40 , 06-Дек-21, (11) –3   // миграция на более новые версии у mysql на порядок проще мультимастер galera в , Gemorroj (ok), 11:55 , 06-Дек-21, (17)   Когда работаешь с ORM вообще пофиг , AleksK (ok), 12:02 , 06-Дек-21, (21) –9   ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят , x3who (?), 12:06 , 06-Дек-21, (22) +2   Вот именно, я работаю со своей объектной моделью, мне пофиг на то что там происх, AleksK (ok), 12:13 , 06-Дек-21, (23) –8   Понятно Упёрся в кривую ORM, свалил всё на RDBMS , Онаним (?), 21:00 , 06-Дек-21, (137) –1   Понятное дело если бы ты её писал то она бы летала и была бы сделана идеально Э, AleksK (ok), 23:07 , 06-Дек-21, (153) –2   Не переживай, не потерял , Онаним (?), 23:15 , 06-Дек-21, (154) –1   Когда работаешь с patroni - тоже, keydon (ok), 12:19 , 06-Дек-21, (26) +1   а есть менее новые Ну или хотя бы более лучшие , Аноним (40), 12:55 , 06-Дек-21, (40)   enum в постгресе одна из немногих вещей которая мне понравилась В MariaDB я его , Ilya Indigo (ok), 13:15 , 06-Дек-21, (47) –1   Я мог конечно не так понять, но вроде обоснования были такие Там вроде одна из , Аноним (204), 11:57 , 07-Дек-21, (204)   В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - не, www2 (??), 07:25 , 22-Дек-21, (249)   Вы, наверное, про MyISAM В MySQL разные движки , Всем Анонимам Аноним (?), 15:03 , 28-Янв-22, (253)   Насколько помню они вернулись не в совсем обычный MySQL, а в какую-то свою касто, Cykooz (ok), 12:27 , 06-Дек-21, (34)   // Нет Key-value у них - это слой абстракции сверху, а не движок , funny.falcon (?), 14:19 , 06-Дек-21, (69)   А, ну да Но тем не менее они сделали костыль поверх MySQL, т к именно его дв, Cykooz (ok), 14:35 , 06-Дек-21, (77)   В текущей версии postgres половина названных проблем уже не актуальна , Catwoolfii (ok), 20:05 , 06-Дек-21, (121) +2   так причина 171 мы не хотим платить специалистам, поэтому наберём макак по объ, arisu (ok), 21:53 , 06-Дек-21, (147)   Уделывает он только по физическому занимаемому месту для эквивалентных данных , Ilya Indigo (ok), 13:06 , 06-Дек-21, (42) –3   // Ильюшинька, Слон реляционный MVCC честная реализация всех уровней изоляции тран, Наме (?), 13:34 , 06-Дек-21, (56) –4   // Вы не поверите, InnoDB тоже MySQL уже более 10-ти лет по умолчанию InnoDB исполь, Ilya Indigo (ok), 13:50 , 06-Дек-21, (62) –2   Это под вендой Но Инно тоже Слону не конкурент Совершенно разного масштаба явл, Наме (?), 14:01 , 06-Дек-21, (65) –2   Это вы зря Сам InnoDB довольно продвинут Но это лишь слой хранения , funny.falcon (?), 14:22 , 06-Дек-21, (70) +1   Да уже по первому комментарию и так понятно что аноним совершенно не понимает о , Ilya Indigo (ok), 14:33 , 06-Дек-21, (76) –1   Ильюша, ты пишешь на пэхэпэ Эти всё сказано о твоим интеллектуальных способност, Наме (?), 15:57 , 06-Дек-21, (93) –11   Мамин илитарий, угомонись ПХП программисты ничем не хуже сишников и сипипишников, Аноньимъ (ok), 03:00 , 07-Дек-21, (166) –1   ну да, почти как люди две руки, две ноги, две задницы 8230 в одну они едят , arisu (ok), 03:06 , 07-Дек-21, (167)   Я о том, что пэхэпёр вряд ли в свой профессиональной жизни плотно сталкивается с, Наме (?), 10:42 , 07-Дек-21, (186) –1   Под какой виндой, что ты несёшь Никто уже нигде лет 15 не использует MyISAM А I, vitalif (ok), 15:18 , 06-Дек-21, (85) +4   Практически везде Просто в силу того, что ISAM для многих задач достаточен , Наме (?), 15:59 , 06-Дек-21, (94) –1   Ты можешь объяснить, чем вакуум хуже лучше отдельных UNDO-сегментов или писани, Наме (?), 16:05 , 06-Дек-21, (95)   Это может сделать любой Это хорошо отсутствием блокировок и гарантированной про, _hide_ (ok), 10:39 , 07-Дек-21, (185) –1   Каких ещё блокировок Вот есть у тебя ряд реализаций MVCC, одна хранит историю в, Наме (?), 10:47 , 07-Дек-21, (187)   Мы скоро обсуждать будем ассемблерные вставки Кто это пишет дифы Никто никаких, _hide_ (ok), 11:06 , 07-Дек-21, (194)   Оракл, например, пишет диффы образно выражаясь, там что-то вроде инструкций р, Наме (?), 11:33 , 07-Дек-21, (199)   Это микрооптимизация поверх определенных типов данных, которая даёт существенный, _hide_ (ok), 11:42 , 07-Дек-21, (201)   Конечно-конечно, никакого вакуума Только православный optimize table Ну и что , Аноним (103), 16:48 , 06-Дек-21, (103) +2   Нет, это и близко не одни и те же яйца Одна чистит БД от призраков и освобожд, Наме (?), 17:13 , 06-Дек-21, (109)   Какую еще пересортировку Из таблицы удаляются осиротевшие или невалидные данн, _hide_ (ok), 10:48 , 07-Дек-21, (188)   Ты не в курсе У Слона счётчик циркулярный, ещё и меридианный Уроборос этакий, Наме (?), 11:30 , 07-Дек-21, (197)   А вот это в корне не так, если говорить о б-жественном InnoDB InnoDB не поддерж, Аноним (192), 10:56 , 07-Дек-21, (192)   Если InnoDB не наполнять очень хитрым образом - необходимости в OPTIMIZE TABLE о, Онаним (?), 20:58 , 06-Дек-21, (136)   Точнее сказать - если не удалять из нее данные , Аноним (192), 10:49 , 07-Дек-21, (189)   Перепутали с постгрёй и вакуумом InnoDB - это не постгря, она умеет заполнять ос, Онаним (?), 10:51 , 07-Дек-21, (190) –1   Вообще-то умеет но чтобы это узнать надо прочитать документацию , Аноним (207), 12:29 , 07-Дек-21, (207)   А вакуум над ibdata1 не помешал бы Полное резервное копирование с последующим в, www2 (??), 07:30 , 22-Дек-21, (250)   У мускула определенно есть некоторые плюсы в сравнении со слоном, но только не я, Catwoolfii (ok), 20:08 , 06-Дек-21, (122) +2   // Я хоть от одного мамкиного слонёнка конкретику услышу с примерами и пруфами, или, Ilya Indigo (ok), 20:17 , 06-Дек-21, (124) –2   unsigned нет в SQL стандарте int1 это для тех кто не умеет boolean int3 вообще, fuggy (ok), 10:28 , 07-Дек-21, (182) +1   // Зато есть отсутствие vacuum, которое автоматически улучшает куда больше, чем тот, Онаним (?), 10:53 , 07-Дек-21, (191)   Вакуум это лишь отложенное амортизированное время операции на вставку удаление, , fuggy (ok), 14:26 , 07-Дек-21, (216) +1   Так, на вскидку, а есть ли в PostgreSQL аналог MEMORY таблицы Вообще проблема о, minonA (?), 15:27 , 06-Дек-21, (87)   // Я сужу по тому как работал мой проект на рельсах Загрузка базы в проект из yaml, AleksK (ok), 16:45 , 06-Дек-21, (102) –1   // Ну, на рельсах можно и постгрю, хуже уже не будет , Онаним (?), 20:57 , 06-Дек-21, (135) +3   Постгрес нравится, но девелопер похож на обиженку- видимо чего-то недодали , А где же каменты (?), 18:56 , 06-Дек-21, (116) –1   дак я уже, Аноним (3), 11:22 , 06-Дек-21, (3) +4 // А я никогда мускуль и не использовал , Аноним (44), 13:11 , 06-Дек-21, (44) +1 // А я его еще больше ку c , Аноним (234), 06:46 , 09-Дек-21, (234) +1 Сейчас будет холивар Я за Postgres , Перастерос (ok), 11:35 , 06-Дек-21, (8) +7 // так вы женщина , Аноним (1), 12:13 , 06-Дек-21, (24) +1 // у тащмайора спроси, тут поди процентов 80 , Аноним (-), 13:31 , 06-Дек-21, (54) +1 // тут пока одни капитаны, Анончик (?), 03:57 , 07-Дек-21, (168) +2 Они тут слово My нечаянно перед SQL добавили, flexagoon (ok), 11:40 , 06-Дек-21, (10) –13 // И какая альтернатива, о великий эксперт , Прохожий (??), 05:36 , 07-Дек-21, (169) –1 // Да любые NoSQL БД, flexagoon (ok), 11:36 , 08-Дек-21, (223) –1 // На SQL по крайней мере стандарт есть и даже те, кто его не придерживается, изобр, www2 (??), 07:42 , 22-Дек-21, (251) Все зависит от цели Когда много данных и нужна скорость, но целостность - не пр, Всем Анонимам Аноним (?), 15:06 , 28-Янв-22, (254) Использовал и то и другое, особой разницы не заметил Для малых и средних сайтов, Аноним (12), 11:42 , 06-Дек-21, (12) –17 // Рукожоп , Аноним (15), 11:52 , 06-Дек-21, (15) +5 Не знаю чем там сильно отличаются туториалы для малых и средних сайтов, так как , Аноним (16), 11:55 , 06-Дек-21, (16) +6 Вывод ты делаешь малые и средние сайты Больше из твоего комментария нечего поче, Аноним (33), 12:26 , 06-Дек-21, (33) потянет и это просто надо применить Секретную Оптимизацию выгнать на мороз теб, arisu (ok), 21:58 , 06-Дек-21, (148) +2 Ну всё, мария не торт, мускуль не торт, постгрес не торт, и раст нас не спасёт, , Аноним (-), 11:48 , 06-Дек-21, (13) +3 // Кто все Модераторы CoC Ах, увольте , Rev (?), 12:21 , 06-Дек-21, (29) +3 // Если бы всё было так просто Один из ключевых разработчиков забросил Rust Wasm, , topin89 (ok), 14:51 , 06-Дек-21, (81) +2 // Отличная ссылочка Читается на одном дыхании как один большой анекдот Только эт, Kuromi (ok), 17:56 , 06-Дек-21, (113) Всегда остаётся Хаскель , Аноним (33), 12:25 , 06-Дек-21, (31) +1 Вся надежда на Монго, Аноним (41), 12:57 , 06-Дек-21, (41) –2 // умерла в далеком 11м году, Аноним (-), 13:30 , 06-Дек-21, (53) +2 // Очень зря MongoDB вполне себе надёжная и удобная в эксплуатации база в наши дни, funny.falcon (?), 14:28 , 06-Дек-21, (73) –1 первая же ссылка https github com Percona-Lab mongodb_consistent_backupсам не , лютый жабби__ (?), 15:54 , 06-Дек-21, (92) –1 MySQL всегда был игрушкой для небольших сайтов Для определённого масштаба вполн, Простоник (ok), 11:58 , 06-Дек-21, (19) // Ты ведь сейчас вордпресс имел ввиде и что УГ, да И правильно сделал , Аноним (33), 12:24 , 06-Дек-21, (30) +3 // Зевая Я не знаю что там хранит вордпресс и в каком виде, но хранить в подобно, Простоник (ok), 12:39 , 06-Дек-21, (38) –4 Alibaba так не считаетhttps www youtube com watch v 4Yhn2Zq3mHA, mamba (?), 18:44 , 06-Дек-21, (115) +3 // у них свое ответвление MySQL с 2008-2009 года Там от родного MySQL только назва, ddd2 (?), 06:36 , 07-Дек-21, (171) // Админ у них просто героический Для hi load эта штука не имеет необходимых механ, Простоник (ok), 07:44 , 07-Дек-21, (172) Думаю, их 171 сарайчики и землянки 187 больше походят на Форд-Нокс , funny.falcon (?), 08:28 , 07-Дек-21, (175) –2 это чо за тачка , Аноним (219), 15:08 , 07-Дек-21, (219) +2 Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт Окей, Онаним (?), 20:56 , 06-Дек-21, (134) –2 // вообще-то так и есть но ты этого всё равно не поймёшь, что очевидно по глупости, arisu (ok), 22:01 , 06-Дек-21, (149) +3 Небольших сайтов вроде FB com и pinterest, anonymous (??), 12:23 , 08-Дек-21, (224) Блин InnoDB интересен своей ораклиной структурой данных -- кластерный первичный, kai3341 (ok), 12:00 , 06-Дек-21, (20) +5 // Ну так если нужно нормальный, то для этого Sphinx есть А то что есть это просто , Ilya Indigo (ok), 13:34 , 06-Дек-21, (57) Попутал ты всё Какой кластерный первичный ключ Это в МС Сиквеле типично отно, Наме (?), 13:46 , 06-Дек-21, (58) +1 // А можно ссылочки на развал БД при краше , funny.falcon (?), 14:31 , 06-Дек-21, (75) // Разверни Запусти длительную транзакцию, не завершая её выруби питание Т к дан, Наме (?), 16:10 , 06-Дек-21, (96) –2 че за бред -- все изменения в данных и в том же UNDO сохраняются в REDO, и по, nik (??), 19:57 , 06-Дек-21, (119) Нет, это не так Возможны состояния, когда UNDO не оказалось в REDO, а изменённы, Мимо_проходил (?), 21:09 , 06-Дек-21, (141) Бред Ну или эксплуатация на системе, не умеющей в write barrier - там что угодно, Онаним (?), 20:55 , 06-Дек-21, (133) Словья-то какие воспроизводим Ещё бы знали, что это значит Write barrier т, Мимо_проходил (?), 21:07 , 06-Дек-21, (139) Короче я не знаю, как ты умудрился InnoDB развалить - у меня за долгие годы не п, Онаним (?), 21:08 , 06-Дек-21, (140) У тебя просто не было длинных транзакций А так разваливается и при резком вык, 1 (??), 11:21 , 07-Дек-21, (195) Ну короче да, смысла спорить нет - я хз как вы умудряетесь InnoDB развалить, вид, Онаним (?), 15:28 , 07-Дек-21, (220) И что значит при чём тут WB Когда двиг выставляет fsync fdatasync sync_file_, Онаним (?), 21:10 , 06-Дек-21, (142) Ну и да, какой WAL для UNDO вы вообще собрались писать, если к моменту коммита в, Онаним (?), 21:20 , 06-Дек-21, (143) Могу ещё подсказать как без WB редо развалить Всё не просто, а очень просто мы , Онаним (?), 21:26 , 06-Дек-21, (144) Похоже как раз на частичный коммит REDO в отсутствии WB , Онаним (?), 23:18 , 06-Дек-21, (155) Ну или fsync кто-то бездумно выключил xD, Онаним (?), 23:18 , 06-Дек-21, (156) в MSSQL некластерный первичный индекс если речь не про Azure появился очень оч, penetrator (?), 15:24 , 06-Дек-21, (86) –1 // Не некластерный, а кластерный Кластерней некуда Но это всё словоблудие майковс, Наме (?), 16:12 , 06-Дек-21, (98) –1 некластерный, heap или как хочешь еще, и он там есть и есть очень давноPK в MSSQ, penetrator (?), 16:45 , 06-Дек-21, (101) –1 Heap это, пардон, куча Т е когда данные хранятся вообще вне всякой упорядоченн, Наме (?), 16:59 , 06-Дек-21, (105) –1 https www red-gate com simple-talk databases sql-server t-sql-programming-sql-, penetrator (?), 22:53 , 06-Дек-21, (152) Не серчай Вокруг этой темы перебор всякой терминологии У многих в результате к, Наме (?), 11:43 , 07-Дек-21, (202) Как бы, PK это не индекс, а Constrain -- ограничение первичного ключа Который р, Наме (?), 17:01 , 06-Дек-21, (107) –1 Маленький бесплатный ликбез В МС Сиквеле данные отношения могут хранится либо в, Наме (?), 17:07 , 06-Дек-21, (108) –1 Хотя, малыши, я тут несколько ошибся Когда заказываешь PK к существующему уже о, Наме (?), 17:18 , 06-Дек-21, (110) https dev mysql com doc refman 8 0 en innodb-index-types htmlEach InnoDB table, kai3341 (ok), 23:42 , 06-Дек-21, (159) +1 // Кластерный индекс это хм индекс А Первичный ключ это ограничение Прос, Наме (?), 12:15 , 07-Дек-21, (206) Я настоятельно рекомендую использовать терминологию официальной документации, а , kai3341 (ok), 13:12 , 07-Дек-21, (210) Читать умеешь clustered index это кластерный индекс структура данных такая P, Наме (?), 13:35 , 07-Дек-21, (211) Читать умеешь clustered index это кластерный индекс структура данных такая P, Наме (?), 13:35 , 07-Дек-21, (212) У пользователей MSSQL проблемы с тем, что они умудряются мешать индексы с констр, Онаним (?), 09:19 , 10-Дек-21, (235) Документация с тобой не согласна https dev mysql com doc refman 8 0 en optimi, Аноним (64), 13:58 , 06-Дек-21, (64) // Ознакомьтесь с документацией Между optimize table и autovacuum есть огромная ра, kai3341 (ok), 10:38 , 07-Дек-21, (184) // Зависит от типа нагрузки, с одной без optimize table у вас диск переполнится, а , Аноним (232), 05:40 , 09-Дек-21, (233) Каким образом переполнится диск без optimize table, если innodb прекрасно умее, Онаним (?), 09:21 , 10-Дек-21, (236) Богомерзкое - это писать логи А автовакуум это красота , Аноним (68), 14:18 , 06-Дек-21, (68) +1 // У вас MVCC уже без лога работает И даже с индексами На самом деле нет Постгря в, Онаним (?), 09:26 , 10-Дек-21, (237) // Тьфу плин MVCC ACID, конечно же , Онаним (?), 09:27 , 10-Дек-21, (238) Местные Аноноимы опускают MySQL уже 20-ый год Но только сейчас до одного из раз, Аноним (33), 12:17 , 06-Дек-21, (25) –1 // Если копры его забросят - получится отличный и стабильный продукт Надеемся что , Аноним (-), 12:34 , 06-Дек-21, (36) +1 // Стагнация ещё ни один проект до добра не доводила , Аноним (37), 12:38 , 06-Дек-21, (37) // Пральна, раздать все копрам, и сосать лапу Иначе же стогнация, нелицензионность, Аноним (-), 13:14 , 06-Дек-21, (46) +1 Ой, да ладно Составит компанию Firebird, делов-то , Аноним (103), 16:56 , 06-Дек-21, (104) Наконец-то мы были услышаны Ждём осознания в станах Вордпресса, пехепешников , th3m3 (ok), 13:11 , 06-Дек-21, (45) +5 // Не ждите - у них там религиозный культ , Аноним (55), 13:33 , 06-Дек-21, (55) +1 В станах Вордпресса давно предлагают использовать MariaDB , 123 (??), 14:29 , 06-Дек-21, (74) С новыми проектами - ок, выбор за Postgres Но что делать, где уже MySQL Обновл, devkornev (ok), 12:20 , 06-Дек-21, (27) +1 // Масштабироваться причем вертикально Горизонтально не каждый сможет , Аноним (33), 13:22 , 06-Дек-21, (50) А как там у постгресс с вакуумом , Кондратий Карлович (?), 12:21 , 06-Дек-21, (28) –1 // он идет, анонимчик (?), 12:25 , 06-Дек-21, (32) +3 А как у MySql с optimize table , Аноним (64), 14:01 , 06-Дек-21, (66) // Тут два вопроса 1 Зачем конкретно В большинстве случаев вообще не требуется Е, Онаним (?), 20:52 , 06-Дек-21, (131) Точнее второе даже не вопрос Онлайновая операция это ныне на InnoDB, которая до, Онаним (?), 20:53 , 06-Дек-21, (132) А как там у mysql с ddl в транзакциях Научились уже , cadmi (?), 15:32 , 07-Дек-21, (221) Ну ушли себе и ушли, это их проблемы , Аноним (-), 12:32 , 06-Дек-21, (35) +1 А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил н, An (??), 12:50 , 06-Дек-21, (39) –1 // На маленьком проекте использовал гугл адсенс Подключил скрипт JS и всё Базу не, Аноним (41), 13:10 , 06-Дек-21, (43) +4 Про MySQL в Google Adsense - это миф, никогда он там не использовался Вы видимо, Аноним (48), 13:15 , 06-Дек-21, (48) В mail ru используют джангу вместе с MySQL и им норм Но это совершенно не значи, Аноним (33), 13:19 , 06-Дек-21, (49) Вряд ли ISAM хорош, когда надо много писать в хвост и не нужны транзакции Напр, Наме (?), 13:49 , 06-Дек-21, (61) –2 // На самом деле уже давно нет И даже для логов нет Потому что при обрыве записи э, Онаним (?), 20:47 , 06-Дек-21, (130) 1Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой , Аноним (67), 14:08 , 06-Дек-21, (67) +1 // Ну Слоника со всем всё прекрасно Ещё бы кластеризацию запилили и вообще было бы, Наме (?), 14:53 , 06-Дек-21, (82) –1 // Расскажи как будешь большую базу нагруженного приложения мигрировать на другой х, Аноним (67), 15:02 , 06-Дек-21, (84) А в чём сложность Ну не RAC, конечно, но вполне можно довести до приемлемого ур, Наме (?), 16:16 , 06-Дек-21, (99) –2 Можно, вопрос какой ценой А в случае мускула всё это очень легко и ненавязчиво , Онаним (?), 20:46 , 06-Дек-21, (129) –1 Именно Или пусть расскажет как будет восстанавливать X траназакций котоые удали, Аноним (67), 00:45 , 07-Дек-21, (163) уже давно запилили https netpoint-dc com blog mariadb-galera-3-node-cluster , Alexander (ok), 16:41 , 06-Дек-21, (100) Ну это Мария А это всё тот же ISAM, только навороченный Но я не пробовал, ниче, Наме (?), 17:37 , 06-Дек-21, (112) Вы что-то путаете ---Конечно, помимо достоинств у кластера Galera есть и огранич, Alexander (ok), 20:14 , 06-Дек-21, (123) +1 Какой ISAM, о чём вы InnoDB к ISAM вообще отношения не имеет, это продукт Innob, Онаним (?), 09:32 , 10-Дек-21, (239) лишь бы не брать монгу, Аноним (-), 13:27 , 06-Дек-21, (52) –7 // Действительно, когда нужен скуль почему же не взять монгу, хмм , Аноним (-), 13:47 , 06-Дек-21, (59) +2 Совет в духе переходите с кефира на джек дениэлс , Наме (?), 13:47 , 06-Дек-21, (60) –2 Дык мускуль и задуман как бесплатная поделка для студентов Никто никогда и не г, Аноним (63), 13:51 , 06-Дек-21, (63) –2 // очень любопытная мысль не хотите ее развить Расскажите нам для чего был задум, ыы (?), 14:41 , 06-Дек-21, (78) // Пусть с себя начнет, Аноним (89), 15:31 , 06-Дек-21, (89) вот как рыз вы в кучу мешаете носки с помидорами PHP был задуман для добавления, InuYasha (??), 12:40 , 07-Дек-21, (208) // кто же такой умный задумывал его для хоумпегов которые будут верстаться при низк, ыы (?), 22:15 , 08-Дек-21, (229) Интернет задумывался как сеть для оборонного ведомства, а 640кб в своё время хва, Онаним (?), 09:33 , 10-Дек-21, (240) –1 вещи, которые оказались удобны и востребованы - имеют свойство перерастать себя, Онаним (?), 09:34 , 10-Дек-21, (241) Freax тоже когда-то был личной поделкой под себя любимого, просто чтобы миних на, Онаним (?), 09:37 , 10-Дек-21, (242) Опенсорс в полный рост А как же разработка сообществом Где миллион волонтеро, ыы (?), 14:22 , 06-Дек-21, (71) –1 // Не хотят Орацлу земные поклоны отбивать , Аноним (-), 16:12 , 06-Дек-21, (97) давно используют постгрес и довольны а кто в постгрес нормально не смог 8230 , arisu (ok), 22:10 , 06-Дек-21, (150) +1 А всем ли нужен мощный оптимизатор запросов , minonA (?), 15:30 , 06-Дек-21, (88) –1 // Хороший вопрос Ответ зависит от того, сколько этот оптимизатор будет стоить , Простоник (ok), 15:53 , 06-Дек-21, (91) да потому что сделать из мощного хреновый просто, а вот наоборот 8212 очень , arisu (ok), 22:12 , 06-Дек-21, (151) +1 но в общем виде работа оценивается как доведение его до уровня технологий начал, Аноним (111), 17:27 , 06-Дек-21, (111) А что никто не говорит про Group Replication в MySQL из каропки, которой в Postg, bsdun (?), 18:42 , 06-Дек-21, (114) Вот когда постгрес предложит мне мультимастер из коробки, встроенный колоночный , Имя (?), 19:31 , 06-Дек-21, (118) –1 // Опять 25 Зачем нужен мультимастер Почти любая СУБД тормозит при записи на ди, leap42 (ok), 19:59 , 06-Дек-21, (120) // Мультимастер - это не про производительность Это про возможность продолжить пис, Онаним (?), 20:44 , 06-Дек-21, (128) // В самом деле Кто бы мог подумать На самом деле все транзакции писавшиеся на , ыы (?), 21:01 , 06-Дек-21, (138) +1 Э-э-э, вы точно себе представляете, как репликация работает Я вижу, что нет , Онаним (?), 21:41 , 06-Дек-21, (145) –1 Какая репликация Синхронная Асинхронная Синхронная с кворумом На протоколе к, funny.falcon (?), 08:35 , 07-Дек-21, (176) +1 Та, которая обсуждается Но это слишком сложно, понимаю , Онаним (?), 09:24 , 07-Дек-21, (178) –1 Видимо, для вас действительно сложно , funny.falcon (?), 09:47 , 07-Дек-21, (181) Ну и я же не зря написал с потерей части транзакций Если потеря части данных н, Онаним (?), 21:47 , 06-Дек-21, (146) –1 Если нужен мультимастер , то берём Oracle RAC, а БД размещаем поверх ceph , Наме (?), 13:37 , 07-Дек-21, (213) Вы не слушайте того кто вам такое говорит, он вообще не шарит Когда primary от, leap42 (ok), 08:06 , 07-Дек-21, (173) +2 Согласен на 99 99 Мультимастер действительно более живуч Но действительно тормо, funny.falcon (?), 08:41 , 07-Дек-21, (177) Наоборот мульти-мастер это про производительность Просто единственный реализова, Наме (?), 13:39 , 07-Дек-21, (214) –2 GOOGLE vs ORACLEМужик-же просто отрабатывает подъемные у нового старого работо, Аноним (125), 20:35 , 06-Дек-21, (125) +1 Што, мужику отказали в возможности безальтернативный VACUUM в MySQL добавить Та, Онаним (?), 20:43 , 06-Дек-21, (127) –2 MySQL будучи карманной игрушкой Oracle по определению не может быть конкурентнос, Фан (?), 00:04 , 07-Дек-21, (160) –2 // А натуральные вставляют Должен ли велик быть обязательно чьим-то чтобы вставлять, Аноньимъ (ok), 09:38 , 07-Дек-21, (179) –1 У вас какой уровень IQ, вьюноша Oracle взял свистоподелку и слепил из нее нормал, Старший аноним (?), 10:31 , 07-Дек-21, (183) –1 // Oracle купил не взял, а именно купил за много много долларооов, систему котора, ыы (?), 10:57 , 07-Дек-21, (193) +1 // 1 миллиард долларов США если интересно , ыы (?), 11:28 , 07-Дек-21, (196) к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку , ыы (?), 11:30 , 07-Дек-21, (198) не надо там от продукта жизнедеятельности монти осталось примерно столько же, с, arisu (ok), 12:08 , 07-Дек-21, (205) В чем смысл коммерческой корпорации Oracle вкладывать в MySQL в ущерб своей Orac, Фан (?), 20:55 , 08-Дек-21, (225) // Мускул ниразу не конкурент ораклу Совершенно разные целевые сегменты мускулем, ыы (?), 22:18 , 08-Дек-21, (230) Версий много и все они могут быть правдивы как по отдельности, так и вместе - ди, www2 (??), 13:12 , 23-Дек-21, (252) Выглядит как чувак не смог занимался оптимизацией, которая по итогу оказалась н, Аноним (162), 00:33 , 07-Дек-21, (162) Используйте инструменты по назначению, да не везде будут фишки остальных баз Но, Виктор (??), 05:45 , 07-Дек-21, (170) Не вижу комментариев - зачем они нужны, когда есть SQLite , 1 (??), 11:41 , 07-Дек-21, (200) // Это настолько самособой разумеется, что даже холиварить повода нет , ыы (?), 11:47 , 07-Дек-21, (203) зачем нужны комментарии , Аноним (219), 15:06 , 07-Дек-21, (218) Смешно Не то чтобы они купили май для захоронения, но вообще Oracle скатывает в, InuYasha (??), 12:45 , 07-Дек-21, (209) Что первое что второе - детские погремушки на фоне того же mssql , Аноним (226), 20:59 , 08-Дек-21, (226) –3 // mssql на линухе уже научилась через шаред мемори работать , ыы (?), 22:19 , 08-Дек-21, (231) В MSSQL особо убивает стохастика оптимизатора - финальный план запроса может мен, Онаним (?), 09:40 , 10-Дек-21, (243) // как удивительно сервер видит повторяющиеся паттерны 8212 и оптимизирует под , arisu (ok), 11:02 , 10-Дек-21, (244) // Ды не, если бы он стабильно делал, а там именно стохастика где-то, потому что пл, Онаним (?), 12:09 , 10-Дек-21, (245) ну пробует разные планы, ведёт статистику в принципе, нормальный метод оптимиз, arisu (ok), 12:18 , 10-Дек-21, (246) Ды там дело не в бенчмарке Там проблема проблему трекнуть Оно на половине его с, Онаним (?), 12:31 , 10-Дек-21, (247) точнее понятно, и уже зафиксили Разбили запрос на три и объединение через хран, Онаним (?), 12:33 , 10-Дек-21, (248) 1,2,3,8,10,12,13,19,20,25,27,28,35,39,52,60,63,71,88,111,114,118,125,127,160,162,170,200,209,226

Сообщения

[Сортировка по времени | RSS]

2. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+7 +/–
Сообщение от AleksK (ok), 06-Дек-21, 11:22
Вот кстати тоже не понимаю зачем нужен MySQL если есть Postgres, который уделывает его по всем параметрам.
Ответить | Правка | Наверх | Cообщить модератору

	5. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+7 +/–
	Сообщение от _hide_ (ok), 06-Дек-21, 11:27
	>>> уделывает его По каким параметрам? >>> по всем А мне казалось, что применение PG -- это очень взвешенное и обоснованное решение.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+8 +/–
	Сообщение от funny.falcon (?), 06-Дек-21, 11:30
	Не по всем. Я, как любитель PostgreSQL, ответственно заявляю. Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё актуальны.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	11. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–3 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 11:40
	> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё > актуальны. Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Gemorroj (ok), 06-Дек-21, 11:55
	миграция на более новые версии у mysql на порядок проще. мультимастер (galera в mysql). некоторый синтаксический сахар (работа с enum, например).
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–9 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 12:02
	Когда работаешь с ORM вообще пофиг.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от x3who (?), 06-Дек-21, 12:06
	ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–8 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 12:13
	> ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят. Вот именно, я работаю со своей объектной моделью, мне пофиг на то что там происходит под капотом. Но с Posgtres для меня все работает быстрее, и админить его ИМХО проще и удобнее.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 06-Дек-21, 21:00
	Понятно. Упёрся в кривую ORM, свалил всё на RDBMS.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 23:07
	> Понятно. Упёрся в кривую ORM, свалил всё на RDBMS. Понятное дело если бы ты её писал то она бы летала и была бы сделана идеально. Эх жаль мир потерял такого специалиста.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 06-Дек-21, 23:15
	Не переживай, не потерял.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от keydon (ok), 06-Дек-21, 12:19
	Когда работаешь с patroni - тоже
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	40. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (40), 06-Дек-21, 12:55
	>более новые версии а есть менее новые? Ну или хотя бы более лучшие.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	47. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:15
	> (работа с enum, например). enum в постгресе одна из немногих вещей которая мне понравилась. В MariaDB я его никогда не использую, так как есть более эффективный tinyint unsigned, а соответствия можно в php массивом в константе класса сохранить. Но в посгресе нет ни tinyint ни unsigned но можно определить 1 раз enum и вставлять его в 2 и более таблицы, а если нужно модифицировать то делается это 1 раз.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	204. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (204), 07-Дек-21, 11:57
	>> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё >> актуальны. >Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования >Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает. Я мог конечно не так понять, но вроде обоснования были такие. Там вроде одна из проблем была - массированные обновления строк. У постгреса с этим не очень хорошо (по крайней мере было, как сейчас - не знаю), тормозил нещадно по сравнению с мускулем. Поясню. У других БД (оракл, мускуль...) строка обновляется на том же месте, где валяется (in-place), т.е. ее физическое положение в блоках не меняется, кроме редких случаев. А постгря вместо редактирования старой строки тупо добавляет измененнную новую. Вроде должно быть даже быстрее, типа некий аналог Copy-on-write. Проблемы возникают, когда на таблицу навешаны индексы. Индекс - упорядоченная последовательность значений, где с каждой строчкой индекса хранится ссылка на исходную строку в таблице, в каких блоках она находится по каким смещениям. В оракле-мускуле, если в строке обновляются поля, не входящие в индекс, индекс не редактируется (адрес строки в таблице не поменялся). А вот в постгре даже при обновлении не-индексных полей надо каждый раз искать в индексе и обновлять на адрес новой, обновленной строки - там уже другой адрес, уже в других блоках ошивается строка, т.е в индексе хранится фигня, надо исправить. Т.е. представь, в таблице у тебя один-два-три индекса, для поисков, а ты 24/7 массированно меняешь поля, не входящие в индекс - и совершается куча лишней (в сравнении с мускулем) работы по обновлению индексов, да еще и куча мусора остается в виде старых исключенных строк, которые какой-нибудь автовакуум подобрать должен, периодически внося свои тормоза и задержки.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	249. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от www2 (??), 22-Дек-21, 07:25
	В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - нет. Набегающие толпы читающих клиентов могут надолго заблокировать запись для обновления. А в PostgreSQL каждый читающий клиент будет читать эту запись внутри своей транзакции, а в рамках другой транзакции эта запись будет обновлена, так что следующие читающие клиенты начнут новые транзакции и прочитают уже обновлённую запись. https://ru.wikipedia.org/wiki/PostgreSQL#%D0%9C�...) В общем, для сайтиков, где данные обновляются не так часто, а чаще читаются, MySQL, наверное, подойдёт лучше. Если же данные чаще обновляются, чем читаются, то PostgreSQL подойдёт лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 28-Янв-22, 15:03
	Вы, наверное, про MyISAM? В MySQL разные движки.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Cykooz (ok), 06-Дек-21, 12:27
	Насколько помню они вернулись не в совсем обычный MySQL, а в какую-то свою кастомизацию, с помощью которой они из MySQL сделали Key-Value базу данных. Вероятно тогда это было легче сделать в MySQL, т.к. там есть поддержка разных движков для хранения данных. В Postgres она появилась только недавно. Поэтому не совсем корректно говорить, что они вернулись именно в MySQL, т.к. они фактически перешли на совершенно другой тип базы данных.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	69. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от funny.falcon (?), 06-Дек-21, 14:19
	Нет. Key-value у них - это слой абстракции сверху, а не движок.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Cykooz (ok), 06-Дек-21, 14:35
	> Нет. Key-value у них - это слой абстракции сверху, а не движок. А, ну да. Но тем не менее они сделали "костыль" поверх MySQL, т.к. именно его движок хорошо показал себя с этим "костылём". С тем же успехом они могли взять готовую Key-Value базу, если бы была в тот момент подходящая под требования. Поэтому не очень корректно приводить пример Uber-а, т.к. они MySQL использовали довольно специфично. Примерно как сравнивать Postgres с Redis.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Catwoolfii (ok), 06-Дек-21, 20:05
	В текущей версии postgres половина названных проблем уже не актуальна.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	147. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от arisu (ok), 06-Дек-21, 21:53
	> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё > актуальны. так причина «мы не хотим платить специалистам, поэтому наберём макак по объявлениям» всегда будет актуальна.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	42. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–3 +/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:06
	Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо больше) А так в нём нет ни unsigned, не int1 и int3, и даже ALTER TABLE ... ADD ... AFTER ...; нету. Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка тоже нету! Ох уж эти мамкины уделыватели по всем фронтам...
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	56. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–4 +/–
	Сообщение от Наме (?), 06-Дек-21, 13:34
	> Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо > больше) > А так в нём нет ни unsigned, не int1 и int3, и > даже ALTER TABLE ... ADD ... AFTER ...; нету. > Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка > тоже нету! > Ох уж эти мамкины уделыватели по всем фронтам... Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), а Дельфин по умолчанию ISAM (транзакций и WAL-а нет, но бывают задачи где это всё лишняя нагрузка). Это как ткацкий станок сравнивать с вязальными спицами -- каждый хорош для своих задач.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:50
	> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), Вы не поверите, InnoDB тоже! > а Дельфин по умолчанию ISAM MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где нужна быстрая вставка можно и MyISAM использовать в той же самой БД!
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Наме (?), 06-Дек-21, 14:01
	>> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), > Вы не поверите, InnoDB тоже! >> а Дельфин по умолчанию ISAM > MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где > нужна быстрая вставка можно и MyISAM использовать в той же самой > БД! Это под вендой. Но Инно тоже Слону не конкурент. Совершенно разного масштаба явления.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от funny.falcon (?), 06-Дек-21, 14:22
	Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 14:33
	> Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения. Да уже по первому комментарию и так понятно что аноним совершенно не понимает о чём пишет, а когда его аргументы мною разбиты пишет снова глупость, не понятно зачем вообще упоминая оффтопик, и просит просто поверить ему.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–11 +/–
	Сообщение от Наме (?), 06-Дек-21, 15:57
	Ильюша, ты пишешь на пэхэпэ. Эти всё сказано о твоим интеллектуальных способностях и общей профессиональной эрудии.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Аноньимъ (ok), 07-Дек-21, 03:00
	Мамин илитарий, угомонись. ПХП программисты ничем не хуже сишников и сипипишников. Специалисты и профаны есть везде.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от arisu (ok), 07-Дек-21, 03:06
	> ПХП программисты ничем не хуже сишников и сипипишников. ну да, почти как люди: две руки, две ноги, две задницы… в одну они едят.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 07-Дек-21, 10:42
	> Мамин илитарий, угомонись. > ПХП программисты ничем не хуже сишников и сипипишников. > Специалисты и профаны есть везде. Я о том, что пэхэпёр вряд ли в свой профессиональной жизни плотно сталкивается с потрохами разных СУБД. Ему это просто не надо.
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	85. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+4 +/–
	Сообщение от vitalif (ok), 06-Дек-21, 15:18
	Под какой виндой, что ты несёшь? Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	94. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 06-Дек-21, 15:59
	> Под какой виндой, что ты несёшь? > Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, > причём что важно - там нет грёбаного вакуума) Практически везде. Просто в силу того, что ISAM для многих задач достаточен.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 06-Дек-21, 16:05
	> Под какой виндой, что ты несёшь? > Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, > причём что важно - там нет грёбаного вакуума) Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	185. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от _hide_ (ok), 07-Дек-21, 10:39
	> Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb? Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью операций. Пишем в лог, читаем из данных и лога (причем все проблемы синхронизации и доступности решает движок БД, разве не классно?). Когда не Hello World, а 300 клиентов пишут/читают единовременно из одного набора данных, такие вопросы вызывают лишь улыбку. И да ISAM-кие движки всегда были ReadOnly after write? Или были какие-то решения для обхода ограничений?
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 10:47
	> Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью > операций. Пишем в лог, читаем из данных и лога (причем все > проблемы синхронизации и доступности решает движок БД, разве не классно?). Каких ещё блокировок? Вот есть у тебя ряд реализаций MVCC, одна хранит историю в виде исходных строк в том же месте, где они были до удаления/изменения, другая пишет, условно, диффы в другое место, а на прежнем месте городит сложную структуру из цепных ссылок, третья делает что-то среднее между первым и вторым -- какие-то удалённые строки держит на прежнем месте, какие-то выносит в отдельную помойку, а какие-то изменения просто хранит в виде инструкций в журнале изменений. Какой способ лучше?
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от _hide_ (ok), 07-Дек-21, 11:06
	> Каких ещё блокировок? Мы скоро обсуждать будем ассемблерные вставки? Кто это пишет дифы? Никто никаких дифов в набор данных не пишет (да и в логи пишутся отнють не дифы, а новые значение полей): либо переписывает измененный набор данных/релоцирует его и пишет заново, помечая старые данные как свободное место (MySQL), либо пишет весь блок отдельно и отмечает это в метазаписях как ожидающий вакуума (PG). VACUUM блокирует часть данных при релокации. MySQL-у Optimize Table нужен как таковой, только при использовании запросов вне индекса (при сканировании), PG требует этого "для обслуживания". > какие-то изменения просто хранит в виде инструкций в журнале изменений Хранить инструкции в журнале? Что за бред, такое было когда-то в InnoDB, но уже давно всплыло, а если журнал будет повреждён? Конец атомарности, разрушены внешние ссылки и вообще ахтунг и ручное восстановление. > Какой способ лучше? Для пользователей и разработчик-прикладников, лучше именно гибридный способ с повторным использованием освободившегося места (и фрагментацией как проблемой), потому что это даёт серьезный прирост к скорости (путем нагрузки на CPU и контроллер, но не на IO), нежели полное копирование всех данных при обновлении. Если брать разработчиков этих СУБД, то второй способ хорош тем, что его можно очень качественно отладить и оптимизировать, тем самым заняв нишу систем с низкой степенью отказа.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 11:33
	Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных). Но не всегда. Если у тебя строка огромная, а поменял ты в ней один символ, то могилить (как делает Слон и Инно тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и этим экономится и пространство хранение и оперативное.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от _hide_ (ok), 07-Дек-21, 11:42
	> Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных). > Но не всегда. Если у тебя строка огромная, а поменял ты > в ней один символ, то могилить (как делает Слон и Инно > тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и > этим экономится и пространство хранение и оперативное. Это микрооптимизация поверх определенных типов данных, которая даёт существенный прирост на синтетике. С практической т.з., если запись изменилась, то перезапись выгоднее, как минимум, своей простотой, да и частая посимвольная замена в строке говорит о проблемах совсем другого рода при проектировании приложения. ЗЫ Но да, прикольно, не знал про это
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Аноним (103), 06-Дек-21, 16:48
	Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это те же яйца даже не в профиль.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	109. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 06-Дек-21, 17:13
	> Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это > те же яйца даже не в профиль. Нет, это и близко не одни и те же "яйца". Одна чистит БД от призраков и освобождает счётчик транзакций (изменений), другая проводит пересортировку таблиц.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от _hide_ (ok), 07-Дек-21, 10:48
	> другая проводит пересортировку таблиц. Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи имеет свою цену и одна из них -- большое количество мертвых данных) заполняется сортированным для чтения набором данных и пересчитанными индексами (после релокейта деток, приходится и индексы пересчитывать) > освобождает счётчик транзакций (изменений) В том контексте, которые используется мной, такие действия выполняются при коммите транзакции (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 11:30
	>> другая проводит пересортировку таблиц. > Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем > не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи > имеет свою цену и одна из них -- большое количество мертвых > данных) заполняется сортированным для чтения набором данных и пересчитанными индексами > (после релокейта деток, приходится и индексы пересчитывать) >> освобождает счётчик транзакций (изменений) > В том контексте, которые используется мной, такие действия выполняются при коммите транзакции > (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник) Ты не в курсе. У Слона счётчик циркулярный, ещё и "меридианный". Уроборос этакий. Без вакуума он заканчивается и всё фризится. Ну и чем тогда пурген отличается от вакуума(кроме чистки счётчика)? Риторический вопрос. В действительности, ни одна из реализаций не лучше другой. Это очередная Кока-кола против Пепси-колы. И не коммите, а фиксации.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (192), 07-Дек-21, 10:56
	А вот это в корне не так, если говорить о б-жественном InnoDB. InnoDB не поддерживает OPTIMIZE напрямую, вместо этого все данные из таблицы копируются во временную таблицу, которая потом замещает оригинальную.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	136. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 20:58
	Если InnoDB не наполнять очень хитрым образом - необходимости в OPTIMIZE TABLE обычно не существует.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	189. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (192), 07-Дек-21, 10:49
	Точнее сказать - если не удалять из нее данные)
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 07-Дек-21, 10:51
	Перепутали с постгрёй и вакуумом. InnoDB - это не постгря, она умеет заполнять освобождённые страницы при добавлении данных.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (207), 07-Дек-21, 12:29
	Вообще-то умеет. но чтобы это узнать надо прочитать документацию.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от www2 (??), 22-Дек-21, 07:30
	>Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума) А вакуум над ibdata1 не помешал бы. Полное резервное копирование с последующим восстановлением из резервной копии - так себе альтернатива для вакуума. Но тем, у кого полная резервная копия делается за полчаса, а перерыв в работе в несколько часов не особо критичен, MySQL пойдёт.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	122. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Catwoolfii (ok), 06-Дек-21, 20:08
	У мускула определенно есть некоторые плюсы в сравнении со слоном, но только не язык запросов. Такой огрызок еще поискать надо...
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	124. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 20:17
	> У мускула определенно есть некоторые плюсы в сравнении со слоном, но только > не язык запросов. Такой огрызок еще поискать надо... Я хоть от одного мамкиного слонёнка конкретику услышу с примерами и пруфами, или только один глупый и необоснованный детский бред!?
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от fuggy (ok), 07-Дек-21, 10:28
	> нет ни unsigned, не int1 и int3 unsigned нет в SQL стандарте. int1 это для тех кто не умеет boolean. int3 вообще какая-то эзотерика, никому не нужная. smallint достаточно. Ну уж в количестве типов тягаться с PostgreSQL не стоит. Там есть array, intrange, daterange, xml, json, inet, геометрические типы. Даже банального uuid нет. > ALTER TABLE ... ADD ... AFTER ... В стандарте у колонок нету порядка. Да функция удобная, но без неё можно прожить. Про CONSTRAINT CHECK ничего не хочешь сказать? Он как бы есть, но его нет. И уж сравнивать по фичам MySQL не стоит. Подключаемые движки, это единственное что пока есть. Они хороши только для определённой нагрузки. Зато нет набора типов индексов, с помощью которых можно улучшить некоторые операции.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	191. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 07-Дек-21, 10:53
	Зато есть отсутствие vacuum, которое автоматически улучшает куда больше, чем тот самый набор индексов. Кстати индексы по (даже не хранимым) вычисляемым полям в MariaDB давно можно делать, и поэтому ряд вещей таким способом и решается. Но соглашусь, маразм с отсутствием DESC индексов решён пока только в ванильной восьмёрке.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от fuggy (ok), 07-Дек-21, 14:26
	Вакуум это лишь отложенное амортизированное время операции на вставку/удаление, за счёт чего это операции эти операции выполняются быстро без необходимости копировать строки в REDO. То есть устаревшие версии строк хранятся в самой таблице и раздувают её, что конечно плохо. Вся лишь разница где хранятся старые версии строк и если вакуум выполняется регулярно, то будет лишь небольшой процент мёртвого места. Но вакуум выполняется в фоне и не занимает основной поток операций. Функциональные индексы и PostgreSQL есть, недавно появились и покрывающие индексы, а кроме того там ещё есть полезные частичные индексы, что в разы уменьшает размер индекса. Частичные индексы позволяют проиндексировать только нужные значения для выборки, не включая оставшиеся ненужные строки. А что касается типов индексов, то кроме банального B-tree, есть и более интересные вроде BRIN, Bloom. Гео индексы тоже есть, но они не всем нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от minonA (?), 06-Дек-21, 15:27
	Так, на вскидку, а есть ли в PostgreSQL аналог MEMORY таблицы? Вообще проблема оптимизатора MySQL преувеличена. Да, в Postgres он умнее. Но и в MySQL можно добиться схожих результатов немного подкрутив. А если говорить о простых запросах, что наиболее частый юзер-кейс, MySQL вообще ничем не хуже.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	102. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 16:45
	Я сужу по тому как работал мой проект на рельсах. Загрузка базы в проект из yaml ну просто в разы быстрее при использовании postgres, да и отзывчивость в общем получше. Я не проводил специальных тестов просто общие впечатления от работы на одном и на другом.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
	Сообщение от Онаним (?), 06-Дек-21, 20:57
	Ну, на рельсах можно и постгрю, хуже уже не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от А где же каменты (?), 06-Дек-21, 18:56
	Постгрес нравится, но девелопер похож на обиженку- видимо чего-то недодали.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема