Товарищ кроме sql ничего не видел в жизни. И еще где то прочитал acid круто и только в sql. Но видимо не понял о чем оно

конечно не понял... о чём же может быть ACID как не о "крутости"... DBA - русскоязычное троль-сообщество ?

конечно не понял... о чём же может быть ACID как не о "крутости"... DBA - русскоязычное троль-сообщество ?

Ты так и не назвал ни одной широкопользуемой дб которая не обеспечивает актуальность данных

Ты так и не назвал ни одной широкопользуемой дб которая не обеспечивает актуальность данных

MongoDB поддерживаем консистентность только на уровне документов например, никаких транзакций там нет, это значит что MongoDB это не ACID нифига

либо всё - либо ничего, на то они и транзакции. помер во время записи? timeout на стороне клиента, не удалось записать, "попробуйте позже"

Описанное тобой полностью зависит от клиентского приложения. Что оно будет делать с данными если не получит ответ от базы..

MongoDB поддерживаем консистентность только на уровне документов например, никаких транзакций там нет, это значит что MongoDB это не ACID нифига

Так так и?

Описанное тобой полностью зависит от клиентского приложения. Что оно будет делать с данными если не получит ответ от базы..

fire-and-forget очевидно не обеспечит согласованности данных, нужно дождаться результата операции и убедиться что она прошла успешно... иначе естественно данные могут потеряться, надеюсь это и дураку понятно

Так так и?

...и ещё раз: никакого ACID, если мы оперируем по нескольким документам в 1 "транзакции"

fire-and-forget очевидно не обеспечит согласованности данных, нужно дождаться результата операции и убедиться что она прошла успешно... иначе естественно данные могут потеряться, надеюсь это и дураку понятно

Ну так жди. Кто ж тебе запрещает? Дб то тут причем?

Ну так жди. Кто ж тебе запрещает? Дб то тут причем?

а при том, что бд может сказать всё окей, а потом рухнуть и потерять данные... в этом вся проблема, которая и будет с Redis'кой если не врубить синхронную синхронизацию на диск

а при том, что бд может сказать всё окей, а потом рухнуть и потерять данные... в этом вся проблема, которая и будет с Redis'кой если не врубить синхронную синхронизацию на диск

Ок. То есть если что то не включено из коробки то это не acid?

...и ещё раз: никакого ACID, если мы оперируем по нескольким документам в 1 "транзакции"

Так закрывай сессию после каждого документа. Дб то тут причем?

Ок. То есть если что то не включено из коробки то это не acid?

поумлчанию получается что нет... это всё-равно что говорить что MySQL в ОЗУ, если у неё можно подключить in-memory engine, что поумолчанию не так.. ладно.. это уже придирание к словам, суть от этого не меняется..

главный вопрос сейчас это что автор поста сверху имел ввиду под "дезайните данные под шардинг с самого начала".. вроде сказал что это тема для отдельного поста но такого я пока не нашёл

поумлчанию получается что нет... это всё-равно что говорить что MySQL в ОЗУ, если у неё можно подключить in-memory engine, что поумолчанию не так.. ладно.. это уже придирание к словам, суть от этого не меняется..

Так можно же. В этом же и смысл, можешь собрать что хочешь. Но чем то придется пожертвовать.

В общем в наше время бегать и лечить за acid, такое себе

MongoDB поддерживаем консистентность только на уровне документов например, никаких транзакций там нет, это значит что MongoDB это не ACID нифига

https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb

https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb

не прошло и 5 лет

ну как бы acid в nosql это тебе не в тапки гадить

ну как бы acid в nosql это тебе не в тапки гадить

да ясное дело что это нелегко, но вопрос же был есть ли не-ACID бд в наше время, и они однозначно есть

да ясное дело что это нелегко, но вопрос же был есть ли не-ACID бд в наше время, и они однозначно есть

Но ты их не знаешь:) да и сам acid большинсиву никуда не упирался

да ясное дело что это нелегко, но вопрос же был есть ли не-ACID бд в наше время, и они однозначно есть

уже отвечал

Clickhouse

а при том, что бд может сказать всё окей, а потом рухнуть и потерять данные... в этом вся проблема, которая и будет с Redis'кой если не врубить синхронную синхронизацию на диск

https://redis.io/topics/persistence

LASTSAVE

ну и редис - это не про транзакции в целом

это для кэша

https://www.google.ca/amp/s/www.javaworld.com/article/2078841/enterprise-java/datastax-ceo--let-s-clear-the-air-about-nosql-and-acid.amp.html

это для кэша

вот именно в этом я и вижу проблему, что в основном люди ставят медленную СУБД и обвешивают её со всех сторок динамической бронёй в виде кешей, однако у этого подхода есть недостатки

вот именно в этом я и вижу проблему, что в основном люди ставят медленную СУБД и обвешивают её со всех сторок динамической бронёй в виде кешей, однако у этого подхода есть недостатки

в чем проблема то? чем тебе не нравится вариант взять что-то медленное и закэшировать?

в чем проблема то? чем тебе не нравится вариант взять что-то медленное и закэшировать?

write latency & throughput останутся низкими, плюс cache invalidation problems (due to network split etc.)

твои проблемы никак не связаны с "медленным" и "кэшем"

поэтому бд шардят.. а шарды обвешивают потом снова кэшовой бронёй но... почему ты сразу не расхерачить, или вернее расшардить данные таким образом, чтоб их можно было вообще в persisted in-memory шардах хранить?

притянуто за уши

твои проблемы никак не связаны с "медленным" и "кэшем"

не понял честно говоря, что ты имеешь ввиду

притянуто за уши

Расходимся. Нас либо тролят, либо он настолько далек от реальности что мы его не спасем.

поэтому бд шардят.. а шарды обвешивают потом снова кэшовой бронёй но... почему ты сразу не расхерачить, или вернее расшардить данные таким образом, чтоб их можно было вообще в persisted in-memory шардах хранить?

Ах вот ты про что. Да гавно вопрос, только бюджет дай гугловый

поэтому бд шардят.. а шарды обвешивают потом снова кэшовой бронёй но... почему ты сразу не расхерачить, или вернее расшардить данные таким образом, чтоб их можно было вообще в persisted in-memory шардах хранить?

А выключат ток?

Ах вот ты про что. Да гавно вопрос, только бюджет дай гугловый

поясни

А выключат ток?

я зря чтоли persisted in-memory написал?

А ты знаешь, как оно in-memory и вдруго -- persisted ? Как оно это делает?

А ты знаешь, как оно in-memory и вдруго -- persisted ? Как оно это делает?

лог мы пишем конечно синхронно на диск, из которого в случае если машина повалится мы всё восстановим и никаких данных не потеряем. Суть в том, что и кэш и store у нас в 1 месте, что позволяет избежать лишних прыжков по сети и сам кэш всегда up to date

лог мы пишем конечно синхронно на диск, из которого в случае если машина повалится мы всё восстановим и никаких данных не потеряем. Суть в том, что и кэш и store у нас в 1 месте, что позволяет избежать лишних прыжков по сети и сам кэш всегда up to date

Ну, и теперь если у тебя охеренное колическтво данных там, как думаешь, как быстро они будут из логов подниматься?

лог мы пишем конечно синхронно на диск, из которого в случае если машина повалится мы всё восстановим и никаких данных не потеряем. Суть в том, что и кэш и store у нас в 1 месте, что позволяет избежать лишних прыжков по сети и сам кэш всегда up to date

однако тут я конечно таки опять не совсем уверен... ибо что если у нас транзакция по данным меж шардов... поэтому мне и интересно, каков приблизительно алгоритм шардинга данных, я в этом честно говоря не разбираюсь абсолютно пока-ещё

Ну, и теперь если у тебя охеренное колическтво данных там, как думаешь, как быстро они будут из логов подниматься?

по сути, если учесть что в таких базах как tarantool указываются скорости cache population on cold start в 500 мб/с то вполне быстро поднимется и прогонит логи

10 минут? 20 минут?

Алгоритм шардинга простой. Напр. все пользователи из Москвы лежат на сервере 1 ИЗ Питере на сервере 2 из Воронежа на сервере 3 и так далее.

по сути, если учесть что в таких базах как tarantool указываются скорости cache population on cold start в 500 мб/с то вполне быстро поднимется и прогонит логи

На ссд в рейде? И накой тогда в памяти кешировать? А если терабайт?

На ссд в рейде? И накой тогда в памяти кешировать? А если терабайт?

если данных больше чем скажем 128 гигов то тема про ОЗУ провальная поумолчанию.. но.... у кого такие бд то?! у Facebook и YouTube?

по сути, если учесть что в таких базах как tarantool указываются скорости cache population on cold start в 500 мб/с то вполне быстро поднимется и прогонит логи

Ну, я вот не знаю. Как минимум, данные там должны лежать в таком же виде, как в БД, это значит, что там их должно быть столько же по объёму примерно, значит, скорость чтения с диска примерно, с такой скоростью они в БД появятся. Я не уверен, что это быстро.

если данных больше чем скажем 128 гигов то тема про ОЗУ провальная поумолчанию.. но.... у кого такие бд то?! у Facebook и YouTube?

Сервера с терабайтами оперативки как не редкость и не нечто необычнон

если данных больше чем скажем 128 гигов то тема про ОЗУ провальная поумолчанию.. но.... у кого такие бд то?! у Facebook и YouTube?

Гы, да тут через день приходит такой очередной чел, и говорит, что же ему делать с такими объёмами...

если данных больше чем скажем 128 гигов то тема про ОЗУ провальная поумолчанию.. но.... у кого такие бд то?! у Facebook и YouTube?

Но я бы на загрузку 128гигов посмотрел. Там не 20 минут нифига

Ну, я вот не знаю. Как минимум, данные там должны лежать в таком же виде, как в БД, это значит, что там их должно быть столько же по объёму примерно, значит, скорость чтения с диска примерно, с такой скоростью они в БД появятся. Я не уверен, что это быстро.

я ж говорю, если мы говорим о бд больше чем ~100 гигов, то это уже кейс не для такого вида бд речь то о low latency & high read/write throughput а не про archiving

Сервера с терабайтами оперативки как не редкость и не нечто необычнон

дорого)

Но я бы на загрузку 128гигов посмотрел. Там не 20 минут нифига

А сколько?

я ж говорю, если мы говорим о бд больше чем ~100 гигов, то это уже кейс не для такого вида бд речь то о low latency & high read/write throughput а не про archiving

У меня впечатление что ты изобретаешь кассандру

Но я бы на загрузку 128гигов посмотрел. Там не 20 минут нифига

в любом случае cold start СУБД обвешанной кэшами будет медленее

У меня впечатление что ты изобретаешь кассандру

что значит "изобретаю"?

я что, key-value db собрался пилить?))

упаси господи

лог мы пишем конечно синхронно на диск, из которого в случае если машина повалится мы всё восстановим и никаких данных не потеряем. Суть в том, что и кэш и store у нас в 1 месте, что позволяет избежать лишних прыжков по сети и сам кэш всегда up to date

Редис лог не пишет синхронно

Ну я вот в таких БД не понимаю нихера. Это гавно какое-то а не бд. Я не понимаю нафига они нужны

я ещё раз повторю свой вопрос: "как правильно шардить данные?"

Так что я лично пасс дальше базарить

я ещё раз повторю свой вопрос: "как правильно шардить данные?"

Я тебе сказал выше

Редис лог не пишет синхронно

по умолчанию, можно же вроде и синхронно писать?

ERROR: S client not available

А точно не скажет никто -- от задачи зависист

я ещё раз повторю свой вопрос: "как правильно шардить данные?"

От нагрузки

я ж говорю, если мы говорим о бд больше чем ~100 гигов, то это уже кейс не для такого вида бд речь то о low latency & high read/write throughput а не про archiving

Тебе надо минимальное латенси на все 109гб постоянно? ?

Что-то ты не так делаешь с данными...

А точно не скажет никто -- от задачи зависист

да это понятно... интересны были скорее общие принципы

по умолчанию, можно же вроде и синхронно писать?

Я не просто так кидал ссылки на документацию

Ну я вот в таких БД не понимаю нихера. Это гавно какое-то а не бд. Я не понимаю нафига они нужны

Как обычно. Если че не понимаю то гавно оно и не нужно никому

Ну, я не понимаю...

Я не просто так кидал ссылки на документацию

ну вот, тогда в чём проблема? по умолчанию не надёжен, но по желанию может превратиться в primary database

ну вот, тогда в чём проблема? по умолчанию не надёжен, но по желанию может превратиться в primary database

Редис не будет примари

У этой бд свои задачи

Я разрабатывал СУБД, которая встраивалась в видеокамеры и лазерные принтеры. Нахуя в видеокамере СУБД -- я не понимаю...

я что, key-value db собрался пилить?))

У меня впечтление что ты начитался всяких слов. Но они у тебя сами по себе. И потому ты их не связываешь и не понимаешь о чем говоришь

Люди делают очень много ебанутых вещей...

Ну я вот в таких БД не понимаю нихера. Это гавно какое-то а не бд. Я не понимаю нафига они нужны

ну тогда храните все данные большого сервиса на MySQL, поймёте

ну тогда храните все данные большого сервиса на MySQL, поймёте

Мускул гавно

Мускул гавно

любой SQL, в принципе

Мускул гавно

+1 я бы не брался в него играть вообще

Редис не будет примари

и тем не менее, в некоторых случаях его можно именно как primary юзать

а при том, что бд может сказать всё окей, а потом рухнуть и потерять данные... в этом вся проблема, которая и будет с Redis'кой если не врубить синхронную синхронизацию на диск

мы уже выяснили, что постгре тоже от такого не защищен

write latency & throughput останутся низкими, плюс cache invalidation problems (due to network split etc.)

как связана инвалидация кэша с network partition?

У меня впечтление что ты начитался всяких слов. Но они у тебя сами по себе. И потому ты их не связываешь и не понимаешь о чем говоришь

началось с того, что я узнал про существование такой твари как Tarantool и мне стало интересно, есть ли ему альтернативы, кто-то делает похожее? Оказалось, что REDIS, который не обладал подобным функционалом к тому времени, когда я первый раз с ним столкнулся - в этом плане немного продвинулся... меня заинтересовала модель расшарденной бд, где шарды - persisted in-memory бд'шки и вот я начал в эту сторону копать..

я зря чтоли persisted in-memory написал?

PERSISITED IN-MEMORY

PERSISITED IN-MEMORY

ну что опять?

по сути, если учесть что в таких базах как tarantool указываются скорости cache population on cold start в 500 мб/с то вполне быстро поднимется и прогонит логи

500 мб/с - это если ты некомпрессированные данные с обычной ссд прямо в память грузишь. Так вот, такого не бывает.

ну что опять?

ну как бы одно из двух только

Алгоритм шардинга простой. Напр. все пользователи из Москвы лежат на сервере 1 ИЗ Питере на сервере 2 из Воронежа на сервере 3 и так далее.

отвратительно

500 мб/с - это если ты некомпрессированные данные с обычной ссд прямо в память грузишь. Так вот, такого не бывает.

бывает, если у тебя данных не больше чем ОЗУ

Алгоритм шардинга простой. Напр. все пользователи из Москвы лежат на сервере 1 ИЗ Питере на сервере 2 из Воронежа на сервере 3 и так далее.

и для каждого мухосранска отдельный сервер?))

типа того

Но это конечно плохой пример в том смысле, что юзеров ясное дело не одинаково в разных городах.