в каком месте?)

ну почитай хоть про релизы, начиная с 9.4, и не задавай таких вопросов

а как там обстоят дела с поиском, ты знаешь?

как обстоят дела в поисках в документах. просвяти. чтобы рекурсия, схемалесс, вот это вот всё

hashstore?

JSON/JSONB

для key-value hashstore не лучше будет?

для key-value hashstore не лучше будет?

у него document-oriented

а, ну так-то да

SQLAlchemy - subquery in a WHERE clause http://stackoverflow.com/q/6206600/974317

видел это

короче, если надо крутой поиск - бери Elasticsearch, он хороший. Если надо более четкие индексы и фильтрацию хитрую по JSON-полям документов - то postgresql

хоть голый sql делай

запарился

в остальных случаях уже тонкости, иногда и какая-нибудь cassandra заходит отлично

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

а монгу не бери, это реально какашка

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

ну, тут ты не совсем прав :) проблема только в том, что тренд есть, а нормальных баз мало

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

наверное, это как раз использование не по назначению, раз все эти проблемы всплывают

это потому что нет назначения

оно тупо трудоёмко и всё

это просто не решает твои задачи, вот и все

оно тупо трудоёмко и всё

опять же, зависит от задачи

@Enchantner Что то да и изменила но, я думаю это не сработает... https://github.com/Marina-chan/telegram_poster_bot/blob/master/bot/main.py

задача key-value - охренительно скейлиться, чего не умеют реляционки

но это переносит всю говнологику на уровень приложения

@yui_meow а ботов с вебхуками писать уже не модно?

опять же, зависит от задачи

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

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

алхимию и необязательно натягивать на глобус

это просто данность с которой нужно мириться если у тебя прямо очень подходит задача

@yui_meow а ботов с вебхуками писать уже не модно?

у тебя есть тут свой разговор

@Enchantner Что то да и изменила но, я думаю это не сработает... https://github.com/Marina-chan/telegram_poster_bot/blob/master/bot/main.py

а мы на 1 курсе писал бота для связывания разных диалогов вк)

алхимию и необязательно натягивать на глобус

так ничего не умеет

у тебя есть тут свой разговор

я многозадачный ?

@Enchantner Что то да и изменила но, я думаю это не сработает... https://github.com/Marina-chan/telegram_poster_bot/blob/master/bot/main.py

посмотрю сегодня, спасибо

а мы на 1 курсе писал бота для связывания разных диалогов вк)

а я просто пишу ботов что бы заработать на покушать

так ничего не умеет

детектировать изменения в json? да, почти ничего

но это - редкий кейс

если ты в него упираешься - то ты неправильно юзаешь базу

а я просто пишу ботов что бы заработать на покушать

А я парсеры хнык хнык

ящетаю, key-value база должна решать две вещи

быструю вставку-чтение и правильную работу со schemaless без выпадения в трейсбеки

если ты в него упираешься - то ты неправильно юзаешь базу

я в него не упираюсь я просто вынужден каждый раз при редактировании жсона делать flag_modified

я в него не упираюсь я просто вынужден каждый раз при редактировании жсона делать flag_modified

ну, в нормальной архитектуре ты не должен этого хотеть

к тому же сейчас не упираюсь не упираюсь а потом хуяк уперся

у тебя не реляционка

у меня моделька в реляционке у которой есть жсонное поле с аттрибутами

постгря?

да

вобщем там на самом деле много боли

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

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

и у постгри смешные поведения на сложных запросах

я просто к чему веду - не должно быть в архитектуре миграции структуры json в идеале

потому что это другой тип хранилища вообще

в тебе говорит монго адепт )

миграции есть всегда это базис вообще

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

миграции есть всегда это базис вообще

да, если разговор идет о реляционках

на фронтенде чуть табличку подверстали и вместо инта шлется строка, всё пиздец нужна миграция

key-value работает не так

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

это тоже миграция

это тоже миграция

миграция может быть частным случаем

но редким

ничего не знаю. схема меняется, старые данные под новую схему обновляются => миграция

нету схемы в key-value хранилищах в общем случае

что бы там ни обновилось - это проблемы твоего уровня приложения

если прям совсем критичное изменение и надо срочно заапдейтить все записи - тогда да, мапредьюс

но это редкий случай

key-value должен быть максимально простым, в этом его суть

миграциям в этой архитектуре места нет по сути

ERROR: S client not available

что бы там ни обновилось - это проблемы твоего уровня приложения

ну при каком то наивном взгляде все проблемы в голове. а при конкретизации уже появляются новые понятия

ну при каком то наивном взгляде все проблемы в голове. а при конкретизации уже появляются новые понятия

ну я просто ковырял довольно много таких хранилищ

еще раз - ты ожидаешь от базы данных. твои юзеры ожидают от базы данные

еще раз - ты ожидаешь от базы данных. твои юзеры ожидают от базы данные

разумеется, и?

каким боком тут вдруг схема появилась?

и данные в базе должны соответствовать хоть немножко этим ожиданиям

ожидания = схема

и данные в базе должны соответствовать хоть немножко этим ожиданиям

данные никому ничего не должны

данные в key-value - это блоб по сути, все

иногда его можно немножко кверить, но в целом это блоб

т.е. читаем рандом и пытаемся интерпретировать его как мы хотим ?

и правильный способ в нем что-то поменять (хотя этого делать особо не надо) - это писать мапредьюс

это блоб на уровне хранения а на уровне аппликации мы ожидаем его распарсить

это блоб на уровне хранения а на уровне аппликации мы ожидаем его распарсить

именно

и мы о нем даже там знаем только то, что это json и что в нем есть пара таких и таких полей. но тут и смысл schemaless - тебе не надо об этом думать вообще

не надо миграции писать

и правильный способ в нем что-то поменять (хотя этого делать особо не надо) - это писать мапредьюс

ну ты отрицаешь что поменять это "миграция" ?

ну ты отрицаешь что поменять это "миграция" ?

я более общим термином оперирую

а не надо более общим

миграция - это что-то из мира реляционок

у более общего нет смысла

отнюдь

миграция - это что-то из мира реляционок

миграция это раньше ты хранил int но с како го то времени хочешь хранить {'value': int, 'type':int}

/thread

когда ты говоришь о большом распределенном key-value хранилище - там нет и не может быть никаких миграций

есть миграция, когда schemaless хранило данные в одном формате, а теперь хранит в новом, а мы не хотим в коде иметь преобразование из старого в новый или наоборот

миграция это раньше ты хранил int но с како го то времени хочешь хранить {'value': int, 'type':int}

вот и делай это в реляционках, schemaless key-value к этому отношения не имеет

в key-value может поменяться принцип именования ключей

когда ты говоришь о большом распределенном key-value хранилище - там нет и не может быть никаких миграций

продолжая мысль - там не миграции, а джобы, операции, вычисления

>а мы не хотим в коде иметь преобразование из старого в новый или наоборо но мы всёравно вынуждены это делать алё

короче говоря, мапредьюс и все такое

продолжая мысль - там не миграции, а джобы, операции, вычисления

тоесть миграции ?