https://www.opennet.me/openforum/vsluhforumID3/126049.html Штайнар Гундерсон (Steinar H. Gunderson), один из авторов библиотеки сжатия Snappy и участник разработки IPv6, объявил о возвращении в компанию Google, в которой в своё время занимался разработкой сервисов поиска по изображениям и offline-картами, но теперь будет вовлечён в разработку браузера Chrome. До этого Штайнар в течение пяти лет работал в Oracle над модернизацией оптимизатора СУБД MySQL. Заметка Штайнара примечательна критическим отношением к перспективам MySQL и рекомендацией переходить на PostgreSQL...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56287<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#254 Fri, 28 Jan 2022 12:06:43 GMT Все зависит от цели. Когда много данных и нужна скорость, но целостность - не проблема, то почему бы нет.<br>Хотя я согласен, Гугл даже строит новую базу себе типа SQL, называется Spanner. Вначале думали да, все проблемы можно возложить на код, но потом пришли к выводу, что проще чтобы база данных этим все-таки занималась.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#253 Fri, 28 Jan 2022 12:03:39 GMT Вы, наверное, про MyISAM? <br>В MySQL разные движки. <br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#252 Thu, 23 Dec 2021 10:12:28 GMT Версий много и все они могут быть правдивы как по отдельности, так и вместе:<br>- диверсифицируют риски,<br>- расширяют количество потенциальных клиентов,<br>- предоставляют полный сервис по решению проблем клиента в комплексе, а не ограничиваются задачей впарить один конкретный продукт всем подряд.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#251 Wed, 22 Dec 2021 04:42:06 GMT На SQL по крайней мере стандарт есть и даже те, кто его не придерживается, изображают что-то более-менее одно и то же.<br><br>Оптимизатор SQL-запросов способен учитывать статистику данных в таблицах, наличие индексов по нужным полям и налету может изменить порядок соединения таблиц. При изменении данных в базе SQL проверяются ограничения, ссылочная целостность. В SQL есть полноценные транзакции с возможностью откатиться до промежуточной контрольной точки.<br><br>А вот на NoSQL никаких стандартов нет, каждый выдумывает что-то своё. И похоже всё это на закат солнца вручную.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#250 Wed, 22 Dec 2021 04:30:09 GMT &gt;Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)<br><br>А вакуум над ibdata1 не помешал бы. Полное резервное копирование с последующим восстановлением из резервной копии - так себе альтернатива для вакуума. Но тем, у кого полная резервная копия делается за полчаса, а перерыв в работе в несколько часов не особо критичен, MySQL пойдёт.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#249 Wed, 22 Dec 2021 04:25:35 GMT В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - нет. Набегающие толпы читающих клиентов могут надолго заблокировать запись для обновления.<br><br>А в PostgreSQL каждый читающий клиент будет читать эту запись внутри своей транзакции, а в рамках другой транзакции эта запись будет обновлена, так что следующие читающие клиенты начнут новые транзакции и прочитают уже обновлённую запись.<br><br>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)<br><br>В общем, для сайтиков, где данные обновляются не так часто, а чаще читаются, MySQL, наверное, подойдёт лучше. Если же данные чаще обновляются, чем читаются, то PostgreSQL подойдёт лучше.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#248 Fri, 10 Dec 2021 09:33:50 GMT (точнее понятно, и уже зафиксили) Разбили запрос на три и объединение через хранимку, в итоге вместо 0.01-2.6 стали почти стабильные 0.07-0.14, плохо, но лучше, чем вот та задница.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#247 Fri, 10 Dec 2021 09:31:18 GMT Ды там дело не в бенчмарке. Там проблема проблему трекнуть.<br>Оно на половине его стохастики допустим где-то костыляется, и вместо 0.01 сек выдаёт 2-3 сек на том же запросе, при _отсутствии_ параллельных запросов - в идеальном сферическом тесте в вакууме. При этом план совершенно другой, чем вызвано - никто не объясняет, как фиксить - непонятно.<br> https://www.opennet.me/openforum/vsluhforumID3/126049.html#246 Fri, 10 Dec 2021 09:18:04 GMT ну. пробует разные планы, ведёт статистику. в принципе, нормальный метод оптимизации &#8212; для реальных нагрузок, где несколько плохих планов нивелируются последующими выигрышами. вполне логично, что при таких раскладах бенчмарки имеют такой же смысл, как и любая другая ИБД.<br>