Написать базу никто не осиливает не потому, что писать стало сложнее, а потому, что еще одно говно класса мускуля уже никого не интересует, а сделать хотя бы аврору уже нужны люди хорошо понимающие, что они делают.
Амазоновскую? Да там тупая репликация под капотом. Говорю как краевед. Вообще все решения Амазона простые и тупые до невозможности. Тем и хороши, кстати. Ну и тем, что омозон практически никогда не убивает свои продукты.
> еще одно говно класса мускуля
Дело не совсем в этом, просто на самом деле производительность никому не нужна. Все отлично знают насколько говном был и является хадуп, но оно стоит просто везде. Зачем стоит, и нахера покупали настолько никто не знает, что есть компании специализирующиеся на: а давайте мы вам что-то хоть как-то полезное на хадупе запустим.
Под капот авроре не смотрел, но смотрел на производительность. До приличной коммерческой базы не дотягивает, но мускулю до нее уже как до луны. Меня это не удивляет, я поработал с нескольким людьми ее пилившими и не сомневаюсь в их профессиональных качествах.
Хадуп - это горизонтальная масштабируемость. Да, тупое, зато можно поднять кластер на десять тысяч нод и чего-нибудь быстро выпотрошить.
Там Postgres внутрях. Что такое "приличная коммерческая" хотелось бы узнать?
> Да, тупое, зато можно поднять кластер на десять тысяч нод и чего-нибудь быстро выпотрошить.
Нельзя. Вертикальная масштабируемость современного железа побеждает горизонтальную хадупа. На 10000 нодов придется бороться с отказами нодов прямо во время квири, что нехило влияет на скорость, т.е. быстро не получится. И я про то, что оказалось 99.9% купивших хадуп не знают зачем он им.
Вообще-то в авроре и постгрес и мускуль (сюрприз, мускуль там тоже есть и он был раньше постгресса) изрядно модифицированные, что положительно сказывается на их производительности.
Приличная коммерческая, это например такая, которая почти линейно масштабируется до 16-socket NUMA, по 60 тредов на горшок. Но я желаю всем иметь кошелек, которым можно такое покупать. Там одна железка пару миллионов стоит, а из нее по хорошему HA кластер собирать надо. Это, кстати, еще и о вертикальном масштабировании. Во-первых, страшно дорого, во-вторых, дальше особенно уже некуда.
> изрядно модифицированные, что положительно сказывается на их производительности
чето не заметил. но ессно модифицированные, как они тогда к ним не блок сторадж присоединили бы
> Приличная коммерческая, это например такая, которая почти линейно масштабируется до 16-socket NUMA, по 60 тредов на горшок
Неясно зачем это надо только. В смысле, что I/O там все равно основной боттлнек, и если для его обслуживания надо 100 тредов - что-то тут не так. Я уж не говорю что оно все бежит поверх OS у которой немного получше и с тредами и с менеджментом I/O. Поэтому нормальная современная база данных - это append log поверх mmap. И тогда никакого бреда с кучей ЦПУ не надо.
> Во-первых, страшно дорого, во-вторых, дальше особенно уже некуда.
Это все в пользу бедных. Гугл и Фейсбук не юзают "коммерческие базы данных" не потому, что у них денег нет, а потому, что их стоимость данных per-row никак не оправдывает такие дикие марджины вендоров.
Ну и по поводу MySQL Aurora: вот держи опен сорс от ютуба, на котором весь ютуб и работает https://github.com/vitessio/vitess Думаю по количеству траффика можно вообще ни с кем не сравнивать - у ютуба все равно длиннее и толще )
Кстати нащот авроры - я так понял, что у постгреса концепция шардинга до сих пор что-то новое и интересное, которое нужно собирать вручную из вручную изготавливаемых под-таблиц, и потом вручную же их индивидуально контролировать есличо? И Амазон, как я понимаю, в этом ничего не изменил?
В общем да. Но если сильно хочется горизонтального скейлинга. Берешь cockroachdb. Сторед процедур нет. В остальном почти постгрес. На самом деле как только нужно странного а не: возьми комп побольше. Начинаются спец решения в любом случае.
Процедуры как раз пофиг. А вот нормальные индексы и нормальный SQL не пофиг. Но постгрес по опыту начиная где-то с миллиарда строк начинает заикаться. На авроре тоже (на самом деле там со стабильностью ещё хуже оказалось, чем в self-managed). Причём данные довольно тривиально shardable, но делать это постгресовыми средствами мучительно. Восход солнца вручную. На cockroachdb не смотрел, пока что.
Ну тут кокроч поможет я думаю. Они шардят по гибридному клоку. Что тупо и прямо. Но очень неплохо работает. В современном постгресе с тейбл-спейсами и роу-левел полиси вроде тоже не так мучительно шардится. Но я не специалист по постгрес шардингу. Может какие-то случаи неоче.
Но в последних версиях можно что-то соорудить, но по технологии "восход вручную", а хочется как в кассандрах всяких - выдать ключ и забыть. Но чтобы индексы при этом работали. Что, конечно, нетривиально, но если б было тривиально, я б и сам написал :)
Ну так а чем плохо? Сильно лучше, чем Yugabyte не сделать. Разве что стордж сам не супер быстрый RocksDB все таки так себе. Надо было lmdb брать. Да и квири не компилируются, а интерпретируются. Но тут вообще мало кто осиливает. В импале смогли, но дизайн агрегатов пролюбили.
Ну не то, чтобы совсем плохо. Но глюки периодически встречаются. Я не к тому, чтобы всё бросать и мигрировать, но желаю быть в курсе альтернатив, на всякий случай. RocksDB это сейчас модно, по-моему. У Confluence и Samza тоже она внутре. С queries там как-то неоднозначно - т.е. они хранятся на сервере (точнее, на серверах) в prepared виде, но как это вид выглядит и что там происходит, я пока не разбирался.
Действительно, никому не надо, клиенты платят конские деньги за железо и лицензии просто так, прикола ради.
Ботлнеков много разных и базы делятся на те, что умеют их разруливать и те, что не умеют.
Также и ОС понятия не имеет о том, как эффективно управлять ресурсами базы и если дать ОС этим заниматься, она все нахрен высвопит, разложит процессы по неправильным нодам, я уж не говорю про оптимизацию для кэша, будет кидать процессы между конвеерами, просрет коммиты, и т.д. В общем бездарно пролюбит как минимум половину производительности.
"Гугл и Фейсбук не юзают "коммерческие базы данных" не потому, что у них денег нет" При чем здесь деньги? RDBMS тупо не масштабируется до их объемов. Сами же приводите ссылку на мидлварь, которая базу использует тупо как KVS. Таки да, это, в общем, единственный способ не обидно использовать мускуль.
Ну почему прикола ради. Просто деньги есть. Мозгов нет. Почему бы не заплатить?
В общем случае никакое разруливание не поможет.
Это все конечно смешная теория. Но на практике имеем дибо старье про медленные диски либо новые к/в сторы но без транзакций. Ну и конечно от rule of thumb: на написание рдбмс невозможно потратить меньше 10 лет, особо тоже никуда не делись.
Я вообще страшное скажу, как только в апликации нужно настоящее анду/реду, коллаборативность и дюрабилити - аппликация сама по себе становится рдбмс. И к сожалению даже сократить путь используя базу под низом нетривиально. Отсюда к/в стор вполне очевидный фундамент.
Значит заработать кучу денег у них мозгов достаточно, а правильно их потратить может только анонимус, который почему-то столько заработать не в состоянии. Годный наброс, только в ту ли сторону повернут вентилятор?..
А про теорию действительно смешно, особенно если учесть, что пишете вы это человеку, у которого TPC с разными буковками были в рабочих обязанностях /отряхивает седые яйца/
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Амазоновскую?
Да там тупая репликация под капотом. Говорю как краевед.
Вообще все решения Амазона простые и тупые до невозможности.
Тем и хороши, кстати. Ну и тем, что омозон практически никогда не убивает свои продукты.
> еще одно говно класса мускуля
Дело не совсем в этом, просто на самом деле производительность никому не нужна.
Все отлично знают насколько говном был и является хадуп, но оно стоит просто везде. Зачем стоит, и нахера покупали настолько никто не знает, что есть компании специализирующиеся на: а давайте мы вам что-то хоть как-то полезное на хадупе запустим.
no subject
Хадуп - это горизонтальная масштабируемость. Да, тупое, зато можно поднять кластер на десять тысяч нод и чего-нибудь быстро выпотрошить.
no subject
Там Postgres внутрях. Что такое "приличная коммерческая" хотелось бы узнать?
> Да, тупое, зато можно поднять кластер на десять тысяч нод и чего-нибудь быстро выпотрошить.
Нельзя. Вертикальная масштабируемость современного железа побеждает горизонтальную хадупа.
На 10000 нодов придется бороться с отказами нодов прямо во время квири, что нехило влияет на скорость, т.е. быстро не получится.
И я про то, что оказалось 99.9% купивших хадуп не знают зачем он им.
no subject
Приличная коммерческая, это например такая, которая почти линейно масштабируется до 16-socket NUMA, по 60 тредов на горшок.
Но я желаю всем иметь кошелек, которым можно такое покупать. Там одна железка пару миллионов стоит, а из нее по хорошему HA кластер собирать надо. Это, кстати, еще и о вертикальном масштабировании. Во-первых, страшно дорого, во-вторых, дальше особенно уже некуда.
no subject
чето не заметил.
но ессно модифицированные, как они тогда к ним не блок сторадж присоединили бы
> Приличная коммерческая, это например такая, которая почти линейно масштабируется до 16-socket NUMA, по 60 тредов на горшок
Неясно зачем это надо только.
В смысле, что I/O там все равно основной боттлнек, и если для его обслуживания надо 100 тредов - что-то тут не так.
Я уж не говорю что оно все бежит поверх OS у которой немного получше и с тредами и с менеджментом I/O.
Поэтому нормальная современная база данных - это append log поверх mmap. И тогда никакого бреда с кучей ЦПУ не надо.
> Во-первых, страшно дорого, во-вторых, дальше особенно уже некуда.
Это все в пользу бедных.
Гугл и Фейсбук не юзают "коммерческие базы данных" не потому, что у них денег нет, а потому, что их стоимость данных per-row никак не оправдывает такие дикие марджины вендоров.
Ну и по поводу MySQL Aurora: вот держи опен сорс от ютуба, на котором весь ютуб и работает
https://github.com/vitessio/vitess
Думаю по количеству траффика можно вообще ни с кем не сравнивать - у ютуба все равно длиннее и толще )
no subject
no subject
Но если сильно хочется горизонтального скейлинга. Берешь cockroachdb. Сторед процедур нет. В остальном почти постгрес.
На самом деле как только нужно странного а не: возьми комп побольше. Начинаются спец решения в любом случае.
no subject
no subject
Они шардят по гибридному клоку.
Что тупо и прямо. Но очень неплохо работает.
В современном постгресе с тейбл-спейсами и роу-левел полиси вроде тоже не так мучительно шардится. Но я не специалист по постгрес шардингу. Может какие-то случаи неоче.
no subject
no subject
no subject
no subject
Сильно лучше, чем Yugabyte не сделать.
Разве что стордж сам не супер быстрый RocksDB все таки так себе.
Надо было lmdb брать. Да и квири не компилируются, а интерпретируются. Но тут вообще мало кто осиливает. В импале смогли, но дизайн агрегатов пролюбили.
no subject
RocksDB это сейчас модно, по-моему. У Confluence и Samza тоже она внутре.
С queries там как-то неоднозначно - т.е. они хранятся на сервере (точнее, на серверах) в prepared виде, но как это вид выглядит и что там происходит, я пока не разбирался.
no subject
Ботлнеков много разных и базы делятся на те, что умеют их разруливать и те, что не умеют.
Также и ОС понятия не имеет о том, как эффективно управлять ресурсами базы и если дать ОС этим заниматься, она все нахрен высвопит, разложит процессы по неправильным нодам, я уж не говорю про оптимизацию для кэша, будет кидать процессы между конвеерами, просрет коммиты, и т.д. В общем бездарно пролюбит как минимум половину производительности.
"Гугл и Фейсбук не юзают "коммерческие базы данных" не потому, что у них денег нет"
При чем здесь деньги? RDBMS тупо не масштабируется до их объемов. Сами же приводите ссылку на мидлварь, которая базу использует тупо как KVS. Таки да, это, в общем, единственный способ не обидно использовать мускуль.
no subject
В общем случае никакое разруливание не поможет.
Это все конечно смешная теория. Но на практике имеем дибо старье про медленные диски либо новые к/в сторы но без транзакций.
Ну и конечно от rule of thumb: на написание рдбмс невозможно потратить меньше 10 лет, особо тоже никуда не делись.
Я вообще страшное скажу, как только в апликации нужно настоящее анду/реду, коллаборативность и дюрабилити - аппликация сама по себе становится рдбмс. И к сожалению даже сократить путь используя базу под низом нетривиально.
Отсюда к/в стор вполне очевидный фундамент.
no subject
А про теорию действительно смешно, особенно если учесть, что пишете вы это человеку, у которого TPC с разными буковками были в рабочих обязанностях /отряхивает седые яйца/
no subject
Если бизнес не в IT то им мозги действительно не нужны для зарабатывания денег.
Да. Это. Медалями трясти не надо. У меня своих есть нормально так.