D
Size: a a a
2020 February 25
AO
Проблемы с миграциями видятся сильно надуманными. Во-первых, для 95% проектов хватает обычной локальной SQL т.к. БД не на столько велика и запросов не так много. А когда много. значит проект высокодоходный нет проблем нанять DBA и создать DB кластер. Примеры есть с бесплатной MediaWiki, движок Wikipedia. Один мастер, пишется только в него и с задержками репликация в десяток или больше slave. Читать из slave, из master как можно реже. Так как операций чтения обычно гораздо больше, это хорошо работает. Причем у них даже MySQL, в котором миграции более проблемные, не везде целостность имеется. Facebook тоже использует MySQL, он еще крупнее, у них правда код закрытый.
если вы архитектор, это ваше решение, какие технологии брать, вы знаете особенности проекта, знаете сильные и слабые стороны различных решений, вы можете решить задачу разными способами, выбор тех или иных систем упростит или усложнит ваш путь
AO
если вам важна высокая доступность, у вас нет сложных и заранее неизвестных запросов, вам не нужны миграции (например, потому что за структурой данных вам удобнее следить через код), то и PostgreSQL может не быть нужен, возможно, вам DynamoDB какой-нибудь подойдёт лучше, он serverless
D
если вы архитектор, это ваше решение, какие технологии брать, вы знаете особенности проекта, знаете сильные и слабые стороны различных решений, вы можете решить задачу разными способами, выбор тех или иных систем упростит или усложнит ваш путь
Я не работал на таких проектах. Я обычный программист из провинции еще и старый к тому же.
AO
вот сейчас все делают микросервисы (ну, не все, но...), в микросервисной среде получается так, что вы уже не имеете 1 огромную базу данных на все сервисы и не можете сделать запрос по 10 таблицам, то есть для этого сейчас нужно использовать API, а потребность в SQL из-за этого существенно уменьшилась, вот это достаточно сильный удар по PostgreSQL/MySQL/.. - нет потребности в SQL - и уже начинаешь задумываться о других способах хранить данные, тебя уже ничего не держит на PostgreSQL...
D
Просто имею общее понятие как это 8-10 лет тому назад делалось в wiki
D
Кластером.
D
И серверами с raid и огромным объемом памяти.
AO
про кластер не очень понял... ну, репликация на любом более-менее серьёзном проекте и так должна быть, разумеется...
D
Сейчас может уже не так
AO
про кластер не очень понял... ну, репликация на любом более-менее серьёзном проекте и так должна быть, разумеется...
чтобы отказ 1 из серверов не привёл к аварии системы
D
Не только. Потому что читается случайно из ноды тем самым сильно снижает нагрузку
D
Скорость записи примерно одна а скорость чтения выше чем больше нод
AO
ну, собственно, мы к чему приходим? есть некие задачи, под задачи подбирается решение)
AO
Я не работал на таких проектах. Я обычный программист из провинции еще и старый к тому же.
ну, с малым бизнесом всё проще - бери любые решения, которые нравятся, они всё равно будут работать 😊
AO
под малый бизнес отлично вот этот облачный serverless подходит
AO
AO
ну, с малым бизнесом всё проще - бери любые решения, которые нравятся, они всё равно будут работать 😊
ладно, тут стоит признать, что подбирать решения не под задачи, а под своё желание поиграться с чем-нибудь новым - это немного эгоистично, но это ведь один из основных плюсов работать с малым бизнесом 😊
KP
ладно, тут стоит признать, что подбирать решения не под задачи, а под своё желание поиграться с чем-нибудь новым - это немного эгоистично, но это ведь один из основных плюсов работать с малым бизнесом 😊
очень часто -- единственный :D
2020 February 26
DA
о, кстати, смотрите, что можно попробовать: https://www.cockroachlabs.com/blog/cockroachdb-for-django/
Только знайте что бэкапы доступны только для Энтерпрайз версии!