Я читал ту статью, на которую вы ссылались в другой теме, но проигнорировали важный абзац в заключении. Нельзя так базы тестить вообще. Уж RDBMS будет занят в реальности многими другими запросами и key value запросы в реальности будут значительно медленней. Кроме того, redis - это далеко не только key value. Списки, expiration и т.п. Вот такие сценарии надо тестить тоже.
Напишу с другого конца. Сам подход к репликации классических реляционок просто неправилен для типичных продуктов, которые мы видем в вебе. Вот именно там шардирование отдельных сущностей с независимой репликацией, как это умеет всякий NOSQL работает понятней и лучше и притягивание туда SQLов за уши - неправильно от слова вообще. То же шардирование - это не про петабайты, а про отдельные домены данных с НЕЗАВИСИМОЙ синхронизацией. Это просто другое, совсем другие принципы и подходы. То, что из RDBMS можно сваять похожее - факт, но применение RDBMS для таких целей - элементарное невладение современными подходами к разработке. К примеру использовать MSSQL для распределённого keyvalue придёт в голову только в пьяном угаре =)
Вв эти репликации запускали между континентами? Я запускал. Такое себе. То, что существует номинально - не означает, что на этом надо строить распределеннве системы. В современном хайлоаде никто не поймет этих аргументов про необхолимость энтерпрайз версий с поддержкой кем.. Индусами в майкрософте? При даунтаймах лайва? Не смешно даже. Если архитеетор построил продукт, зааисимый от внешней поддержки - он профнепригоден. Про нишевое не говорю..
Ну а если прицепить к планшету монитор, клаву и мышку - он до сих пор не десктоп только потому, что софт другой? Сомнительная грань. Результат в виде смонтированых видосов есть? Есть. Значит норм софт.
Я не принижаю MSSQL, я люблю его. У нескольких клиентов только он. Но вот есть задачи, где его притягивать за уши смысла просто нет никакого. В том проекте, где мигрировали на посгрес - всё что нас держало годами от миграции - были килотонны хранимок разной степени тухлости. И вот с появлением LLM - переписали основную кодовую базу за месяц.
есть geo cluster.
стоимость этого решения понимаете? главный вопрос - зачем? что бы было? У нас бизнес деньгами не сорит.
Я не согласен с трактовкой, что всё что не мобайл - то десктоп. В это понятие вкладывается всё таки нечто большее. Чем тогда мобайл от десктопа отличается? Речь ведь вообще по большому счёту о потребительском софте в конечном итоге, даже в конечном результате использования этого софта. Если смонтированый видос на телефоне никак не отличишь от видоса, смотнированного за столом с тремя мониторами и софтом за много килобаксов, телефон становится десктопом?
У любого сервера есть свои лимиты, как бы не вылизывали базу, рано или поздно возникнет вопрос с горизонталкой. И вот тут начинаются нюансы. Реплики какое-то время выручают, но всё равно упираешься во write нагрузку. И приходится шардировать сами данные, причём по материкам. И вот тут MSSQL, как бы это сказать.... Натянуть сову и на глобус можно, но есть способы решать задачу более подходящими инструментами.
Ну не надо тапками кидаться, с компетенцией порядок. Мы не упирались в MSSQL. Его цена была тупо необоснована нашим профилем нагрузки, а возможности роста сковывал.
Лицензия стоит заметных денег. Сам факт, что нужно выбивать заметный бюджет под новые инстансы сковывает руки по архитектуре и начинаешь обвешиваться слоями вокруг SQL, лишь бы этот вопрос не поднимать.
Ну вот с чего потребуется в разы больше инстансов постгреса? Очень сильно от профиля нагрузки зависит. Далеко не всегда вакуум проблема. На своём продукте мы нагрузку на CPU снизили в 2 раза с переходом на пострес. IO плюс минус такой же.
Довольно популярный тревел. Проблема MSSQL в первую очередь - дорогая горизонтальная масштабируемость. В результате базы омоналичиваются, обрастают годовыми кольцами, со всеми вытекающими. Сам то движок мощный, но не дающий ничего такого, что оправдывало бы косты, по крайней мере на "обычных" объёмах.
На счёт MSSQL vs postgress можно побольше деталей? Мы как раз наконец недавно пристрелили последний MSSQL и вздохнули свободней, так как и руки развязали, и косты уменьшили, и производительность подняли. Базы не петабайтные конечно, но и не совсем детские.
Ковбойские катки позволительны, но только при инфраструктуре, позволяющей тестировать их процентом трафика со всем соответствующими метриками. Нет инфраструктуры - значит очень строгий процесс деплоймента и тестирования, независимо от того, на сколько там пригорает у бизнеса.
Проблема с девопсами в том, что они (хорошие девопсы) должны иметь в бекграунде и опыт разработки и опыт запуска / эксплуатации причём под нагрузкой. Обычно это уставшие (выгоревшие) разработчики. Обычные девы часто дальше "а у меня на компе всё работает" не мыслят и к продакшену их подпускать надо очень осторожно. Тем более, если дев замотивирован не особо грамотным менеджером выпускать фичи побыстрее. Нужен человек, который менеджера может отшить, именно поэтому девопс в другой юрисдикции.
По структуре пришёл к такой же, как у автора, но без дат внутри месяца, просто название события. Практика показала, что точная дата не важна (если самих событий внутри месяца не так много, а их не больше десятка - двух, чаще реже).
А на счёт резервных копий - очень хорош и удобен KopiaUI. Делает снапшоты на врешние хранилища по полиси.
Сейчас много видосов ходит с лазерной сваркой. Интересно было вы почитать в этом цикле, что за зверь.
Я читал ту статью, на которую вы ссылались в другой теме, но проигнорировали важный абзац в заключении. Нельзя так базы тестить вообще. Уж RDBMS будет занят в реальности многими другими запросами и key value запросы в реальности будут значительно медленней. Кроме того, redis - это далеко не только key value. Списки, expiration и т.п. Вот такие сценарии надо тестить тоже.
Напишу с другого конца. Сам подход к репликации классических реляционок просто неправилен для типичных продуктов, которые мы видем в вебе. Вот именно там шардирование отдельных сущностей с независимой репликацией, как это умеет всякий NOSQL работает понятней и лучше и притягивание туда SQLов за уши - неправильно от слова вообще. То же шардирование - это не про петабайты, а про отдельные домены данных с НЕЗАВИСИМОЙ синхронизацией. Это просто другое, совсем другие принципы и подходы. То, что из RDBMS можно сваять похожее - факт, но применение RDBMS для таких целей - элементарное невладение современными подходами к разработке. К примеру использовать MSSQL для распределённого keyvalue придёт в голову только в пьяном угаре =)
Вв эти репликации запускали между континентами? Я запускал. Такое себе. То, что существует номинально - не означает, что на этом надо строить распределеннве системы. В современном хайлоаде никто не поймет этих аргументов про необхолимость энтерпрайз версий с поддержкой кем.. Индусами в майкрософте? При даунтаймах лайва? Не смешно даже. Если архитеетор построил продукт, зааисимый от внешней поддержки - он профнепригоден. Про нишевое не говорю..
Ну а если прицепить к планшету монитор, клаву и мышку - он до сих пор не десктоп только потому, что софт другой? Сомнительная грань. Результат в виде смонтированых видосов есть? Есть. Значит норм софт.
Я не принижаю MSSQL, я люблю его. У нескольких клиентов только он. Но вот есть задачи, где его притягивать за уши смысла просто нет никакого. В том проекте, где мигрировали на посгрес - всё что нас держало годами от миграции - были килотонны хранимок разной степени тухлости. И вот с появлением LLM - переписали основную кодовую базу за месяц.
стоимость этого решения понимаете? главный вопрос - зачем? что бы было? У нас бизнес деньгами не сорит.
На много раньше. Как только потребуется локализация нагрузки на другом континенте.
И расскажите, как будете делать что-то уровня TimescaleDB на MSSQL
Macbook Air - это десктоп?
Я не согласен с трактовкой, что всё что не мобайл - то десктоп. В это понятие вкладывается всё таки нечто большее. Чем тогда мобайл от десктопа отличается? Речь ведь вообще по большому счёту о потребительском софте в конечном итоге, даже в конечном результате использования этого софта. Если смонтированый видос на телефоне никак не отличишь от видоса, смотнированного за столом с тремя мониторами и софтом за много килобаксов, телефон становится десктопом?
У любого сервера есть свои лимиты, как бы не вылизывали базу, рано или поздно возникнет вопрос с горизонталкой. И вот тут начинаются нюансы. Реплики какое-то время выручают, но всё равно упираешься во write нагрузку. И приходится шардировать сами данные, причём по материкам. И вот тут MSSQL, как бы это сказать.... Натянуть сову и на глобус можно, но есть способы решать задачу более подходящими инструментами.
Ну не надо тапками кидаться, с компетенцией порядок. Мы не упирались в MSSQL. Его цена была тупо необоснована нашим профилем нагрузки, а возможности роста сковывал.
Лицензия стоит заметных денег. Сам факт, что нужно выбивать заметный бюджет под новые инстансы сковывает руки по архитектуре и начинаешь обвешиваться слоями вокруг SQL, лишь бы этот вопрос не поднимать.
Ну вот с чего потребуется в разы больше инстансов постгреса? Очень сильно от профиля нагрузки зависит. Далеко не всегда вакуум проблема. На своём продукте мы нагрузку на CPU снизили в 2 раза с переходом на пострес. IO плюс минус такой же.
На пару путешественников подписан, днём снимают, ночью на макбуке монтируют. Не нужен уже десктоп для этого.
Довольно популярный тревел. Проблема MSSQL в первую очередь - дорогая горизонтальная масштабируемость. В результате базы омоналичиваются, обрастают годовыми кольцами, со всеми вытекающими. Сам то движок мощный, но не дающий ничего такого, что оправдывало бы косты, по крайней мере на "обычных" объёмах.
На счёт MSSQL vs postgress можно побольше деталей? Мы как раз наконец недавно пристрелили последний MSSQL и вздохнули свободней, так как и руки развязали, и косты уменьшили, и производительность подняли. Базы не петабайтные конечно, но и не совсем детские.
Ковбойские катки позволительны, но только при инфраструктуре, позволяющей тестировать их процентом трафика со всем соответствующими метриками. Нет инфраструктуры - значит очень строгий процесс деплоймента и тестирования, независимо от того, на сколько там пригорает у бизнеса.
Проблема с девопсами в том, что они (хорошие девопсы) должны иметь в бекграунде и опыт разработки и опыт запуска / эксплуатации причём под нагрузкой. Обычно это уставшие (выгоревшие) разработчики. Обычные девы часто дальше "а у меня на компе всё работает" не мыслят и к продакшену их подпускать надо очень осторожно. Тем более, если дев замотивирован не особо грамотным менеджером выпускать фичи побыстрее. Нужен человек, который менеджера может отшить, именно поэтому девопс в другой юрисдикции.
Нынешнему обывателю в данном понимании десктоп вообще не нужен. Котиков на телефоне привычней смотреть.
Многие блохеры на маках монтируют свои видосы и знать ничего не зрают про десктопы
По структуре пришёл к такой же, как у автора, но без дат внутри месяца, просто название события. Практика показала, что точная дата не важна (если самих событий внутри месяца не так много, а их не больше десятка - двух, чаще реже).
А на счёт резервных копий - очень хорош и удобен KopiaUI. Делает снапшоты на врешние хранилища по полиси.