Доступен релиз распределённой СУБД TiDB 4.0, развиваемой под впечатлением от технологий Google Spanner и F1. TiDB относится к категории гибридных систем HTAP (Hybrid Transactional/Analytical Processing), способных как обеспечивать выполнение транзакций в реальном времени (OLTP), так и выполнять обработку аналитических запросов. Проект написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53045
Вот бы MySQL кто-то переписал на Golang была бы хоть польза, а тут непонятно можно на него преейти или нет и чем это грозит.
Что значит "MySQL переписали на Go"? Сделали полностью другую базу со 100% совместимостью с MySQL? Зачем?
Ну как, должен же кто-то тормозить и жрать оперативку? Иначе Intel негодует, новые процы не покупают.
Доо. А пока - всего лишь оракле негодуе, что все на мускул бегут... хотя, постой-ка, не уже и не так, чтобы бегут.Всё-таки, не зря оракл ее купил и «совершенно случайно» положил на неё.
Вроде как MySQL неплохо развивается
Внезапно переписали уже, называется TiDB
лучше на Rust переписать MySQL и PostgreSQL, сразу в космос полетят, без сомнений инфа 100%
Куда же без тебя растомана любимого. Нука расскажи мне как в rust невозможно себе в ногу выстрелить в safe коде, а я тебе потом покажу как можно в три строки отстрелить себе голову в rust, и без всяких unsafe.
о нет, в языке программирования можно наговнокодить. Никогда такого не было!
Именно что можно. Но они же упорно кричат что rust безопасен до немагу и в safe там вообще ничего не сломать и даже код проверять не надо.
Чёт кричат про безопасность Rust в основном хейтеры. Никакого чуда тут нет. Если сильно упростить, то тут просто сделали из набора варнингов и сообщений анализаторов ошибки компиляции.Допустим вот такой код:
int i = 2;
printf("%d %d\n", i++, i++);Что лучше, иметь возможность найти тут ошибку или же невозможность написания кода с такими ошибками вообще?
Лучше иметь мозг.
Неопределенное поведение прозволяет компелятору производить дополнительные оптимизации, поэтому Си всегда будет быстрее недoязычка от тoрмoзиллы.
Могу ответить в том же стиле.UB/UB++ никогда не будут производить столь же оптимизированный код, как и Rust.
Просто по той причине, что время, потраченное на поиск багов, поддержку очередного форка std и прочую возню с кривыми тулзами, никогда не будет использовано на оптимизацию кода.
Как ви понемаете можно просто взять больше времени...
Могу ответить в том же стиле. Код написанный на rust никогда даже близко не приблизится к c\c++
разве незаметно, что это шутка была по поводу переписывания на Rust?
А как-то не очень заметно. Хотя может у меня распознование юмора хромает.
Ничего хорошего на go никогда написано не будет. Как можно на go написать что-то хорошее?
потому что они про to забыли. Вот дорастут до goto тогда сразу спасут весь мир.
>Вот бы MySQL кто-то переписал на Golang была бы хотьНапример, ты . Мы хотим поржать над очередным "клоном gimp для озабоченных"
Ну кстати, гимп и сам такой.. что даже шутить над этим бессмысленно существующим калекой не хочется
Где б еще со всем этим поработать, если мигрировать в Мск с Питером впадлу, удалёнка с таймтрекером - такая себе версия цифрового рабства, а в твоей провинции дай бог если на местных галерах про брокеры очередей слышали))) либо фуллстак на постгре, либо фуллстак на оракле)
Вот не факт, что в Мск кто-то с этим работает. Очень специфичная штука. Ынтырпрайз на такое даже не смотрит. Разве что девопсы где-то втихоря вкорячили.
можно подумать в мск как-то по другому.
>удалёнка с таймтрекеромТвое светлое будующее в постпандемическую эпоху,хе-хе
Новая смузи СУБД... которая по счету? MS, Oracle, IBM, SAP напряглись?
PostgreSQL напрягся...
Это не Смузи СУБД. Это Вок СУБД. Китайцы же пилят.BTW, китайцы знают толк в высоких нагрузках.
Я с интересом наблюдаю за TiDB. Мне кажется, она должна набрать популярность, т.к. вроде они все делают правильно.
Учитывая, что сейчас единственным открытым, популярным, удобным и масштабируемым (take four) решением является MongoDB, у TiDB есть шанс.
> Учитывая, что сейчас единственным открытым, популярным, удобным и масштабируемым (take
> four) решением является MongoDB, у TiDB есть шанс.Ну там, где монга, действительно, у TiDB есть шанс.
Монга кстати хороша, но там, где она хороша, TiDB с его SQL просто не нужен.
Ну если ты не знаешь ничего кроме монги, то это твои проблемы.
no take off - https://www.linkedin.com/company/pingcap/people/эти парни в конце концов всё завалят (ничего личного и никакого расизма).
Что завалят? Активно развивающийся продукт с уже солидной базой клиентов?Конечно, просрать можно и Nokia, и Sun Microsystems. Но согласитесь, что для этого нужно было постараться.
Особенно второй пункт в списке новшеств порадовал, нет, честно!
JANDB
Just Another Not-needed DB
Дарю название.
Посмотрел я на их продакшн-требования для одной ноды... если обычному MariaDB+TokuDB, столько дать, это поделие долго не понадобится. Даже если репликацию и шардинг руками намутить, всё равно выйдет легче и дешевле.
мы не можем ждать пока ты там руками что-то намутишь, у нас смузи скиснет!"Этих денег нам в зарплату все равно не положат!"
1. Я сходу не могу найти «продакшн-требования». Кинете ссылочку?
2. Оптимизация распределённых запросов негораздо более заковыристая штука, чем запросов на локальной машине
3. Ещё налогом на распределенность идут затраты на обмен между узлами
4. Да, TiDB ещё молодая и не все ещё вылизано надо зеркального блеска. Но с каждым выпуском они все быстрее.А теперь скажите, чего вам будет стоить сделать автоматический фейловер? А решардинг? А решардинг с автоматическим фейловером?
Сделать руками шардирование - это легко. Реплику поставить тоже не трудно.
А вот сделать так, чтобы это все работало по щелчку пальцев, и чтобы при падении инцидентах пукан не взрывался от натуги - это не легко. И, к сожалению, за это приходится платить в том числе производительностью.
1. Да пожалуйста, оно в доках (если их читать, конечно) находится легко:
https://pingcap.com/docs/stable/hardware-and-software-requir.../2. Естественно, но идея не нова, NDB Cluster существует лет уже очень много
3. Там же, где и 2.4. Этих "молодёжных" вариаций сейчас пруд пруди. В реальных условиях либо не работают, либо работают с должной производительностью на полтора запроса одновременно, либо требуют неограниченное число ресурсов, при каковом преимуществ перед классическими решениями, кроме красивой саморекламы, по сути не остаётся.
Насчёт "щелчка пальцами" - по опыту, "молодёжные" поделки обычно работают до первого залетевшего дятла. Дальше "щелчок пальцами" переходит в даунтайм или вообще потерю данных.
Кстати если кто пробовал - как там со split brain condition?Самый простой и типовой случай из реального мира - _кратковременный_ (несколько десятков секунд) сетевой split brain между нодами. Рандомный, и не оставляющий ни в одном из сегментов кворума или полного набора данных. При этом частично связность может сохраняться.
Jepsen протестировал TiDB перед выходом версии 3.0 . Был косячок с ретраем транзакций, его выключили по умолчанию. Больше проблем найдено не было.
Ну ок, есть некоторые проблемы. Но, как я понимаю, к split brain они не приводят.
Дело в том, что всегда напрягали и напрягают кластерные "решения", в которых ситуации и поведение при split brain, а особенно - нюансы выхода из таковых - не то, что не расписаны подробно, а вообще пропущены в документации, как будто таковых ситуаций не существует.
MongoDB работает. Работает нормально. Это раз.
Хотя, кончено её уже можно считать вовсе даже "старичковской".Рекомендуемые требования - это не обязательные. Оно запустится у вас и на меньших тачках. Это два.
NDBCLUSTER (also known as NDB) is an in-memory storage engine
The NDBCLUSTER storage engine supports only the READ COMMITTED transaction isolation level.
Это три."молодёжных" вариаций пруд пруди потому, что "старичковских" вариаций открытых (или хотя бы за вменяемые деньги) нет.
Это четыре.
Репликация лучше галеры по задержкам выполнения OLTP?
> Репликация лучше галеры по задержкам выполнения OLTP?Не думаю. Прямая репликация транзакций и сборка/разборка по распределённому KVS - всё-таки разные накладные расходы совершенно.
stored procedures? Не?