Отличный и очень понятный и грамотный доклад! Всё по полочкам. Почерпнул для себя полезные идеи, например, что касается тестовой среды, аналогичной продакшену, спасибо!
раз у ж вы в Амазоне, почему бы не пользоваться ElasticCache для redis и RDS/Aurora для Postgres? Да, оно стоит чуть дороже чем ваши EC2. Но вы на эти переезды, даунтаймы, репликации итд. Потратили больше денег и времени.
Мы жили на одной хрени, переезжаем в другую. Но по факту так и не поняли какая нам СУБД лучше подойдет в том числе и в плане долгосрочных перспектив, а не на пару лет вперед. Тут либо вечно кочевать из одной бесплатной субд в другую, либо сделать решение долговечным и стабильным, купив стабильное, платное и зарекомендовавшее временем решение (Oracle, MS SQL Server, Postgres Pro). Ну или заниматься переездами вечными и вечно кормить тех, кто будет это делать. Или стать частью команды над Open Source-решением и его использовать, но также развивая и это решение. Просто пользоваться Open Source решением без его непосредственного развития-также опасно. Также в традиционном смысле транзакции нерационально использовать в высоко нагруженных системах. Транзакции особенно распределенные реализуются на всех слоях информационной системы, а не только транзакциями СУБД.
Postgres Pro?) Да ладно) с учетом того, что описанные "костыли"(то есть приклад не из коробки в данном случае) все равно будут использоваться... и насколько лучше про чем свободный постгрес - еще вопрос...
@@Алексей-м7ц7й , думаете они взяли открытый постгресс и немного добавили фич, которые невсегда стабильно работают как описано в доке, затем поменяв наклейку с постгресс на постгресс про и зарегистрировали как российское ПО?) На самом деле такое сплошь и рядом-берут опен соурс+добавляют чего-то небольшое=российский софт, а потом идут и говорят, что он может заменить западные аналоги. Хотя сами же слизали с западного ПО)
@@КоддШредингерр вы, конечно, правы, и так происходит часто, но я не считаю это главной проблемой слона. В данном случае слон из коробки - ограниченное ПО, и для указанных решений в любом случае требует других применения других программных продуктов, в отличии от mssql и oracle
Ого, шардирование на уровне кода, connection manager, отсутствие транзакций между шардами, асинхронная репликация (диски в AWS тоже могут биться, ага, посмотрим как асинхронно восстановитесь), сторонний failover через Consul + patroni. Просто тонна денег и сил влито. Есть куда более адекватные замены PostgreSQL, которые делают все это из коробки. Посмотрите в сторону CockroachDB, сэкономите кучу денег и сил.
CockroachDB (NOSQL) энтерпрайс тоже денег просит за сапппорт и фитчи. И сколько денег тайна. У вас есть информация про то, сколько стоит решение уровня энтерпрайс? (название выбрали еще то таракан). Реактивные драйвера под CockroachDB? В чем ее преимущества реальные (не на картинках) перед MongoDB? И интересно сколько стоит найти спеца по CockroachDB на саппорт и много ли таких спецов в РФ. Раньше все пищали про то, что постгре нет спецов (в отличие от оракла), теперь тоже самое говорят про NoSQL. Вы попробуйте такое решение в энтерпрайзе защитить и обосновать. Тут PostgreSQL который обвешан сертификатами ФСТЭК смотрится выгоднее на фоне конкурентов. Я к поклноникам PostgreSQL себя не отношу, но такова реальность
@@namefn3492 порядка 80$ в месяц стоит 1 нода в cockroach cloud (GCP us-west2, 2 vCPU, 60GB). не очень понял почему они nosql - уже года 3 как реляционная база
полтора года переезд внушает, "перенесли небольшую часть данных" и будем еще полтора года переезжать. мне нравится честность докладчика. инстансы редиса стали неожиданно давать лайтанси большую. была nosql bd (+in memory) и вдруг поехали на SQL БД с требованием низкое лэйтанси (странное решение). Пока не понимаю почему туже монгу не выбрали, тем более живут в клауде. Потсгре вообще большое число коннектов сам по себе без сторонних решений выдерживать не может по дефолту, что уже на мысли толкать должно. Шардирование на уровне логики приложения, то есть в коде (без комментариев).
Отличный и очень понятный и грамотный доклад! Всё по полочкам. Почерпнул для себя полезные идеи, например, что касается тестовой среды, аналогичной продакшену, спасибо!
раз у ж вы в Амазоне, почему бы не пользоваться ElasticCache для redis и RDS/Aurora для Postgres? Да, оно стоит чуть дороже чем ваши EC2. Но вы на эти переезды, даунтаймы, репликации итд. Потратили больше денег и времени.
Теперь я понял, вот почему оно так тормозит.
Rm -rf можно было заменить на переименование директории (mv)?!
Не так опасно ведь?!)
Не понял с redis - почему нельзя развернуть кластер? Да и без него можно переехать на машину побольше без downtime
Удалить дирректорию, чтобы зафиксировать мастер? А вырубить сервис или сервер нельзя?
я полагаю они перед удалением должны были остановить postgres ))
Ну и решать требование низкой latency заменой in-memory базы на дисковую - странно, вы вообще проводили тесты?
Мы жили на одной хрени, переезжаем в другую. Но по факту так и не поняли какая нам СУБД лучше подойдет в том числе и в плане долгосрочных перспектив, а не на пару лет вперед. Тут либо вечно кочевать из одной бесплатной субд в другую, либо сделать решение долговечным и стабильным, купив стабильное, платное и зарекомендовавшее временем решение (Oracle, MS SQL Server, Postgres Pro). Ну или заниматься переездами вечными и вечно кормить тех, кто будет это делать. Или стать частью команды над Open Source-решением и его использовать, но также развивая и это решение. Просто пользоваться Open Source решением без его непосредственного развития-также опасно.
Также в традиционном смысле транзакции нерационально использовать в высоко нагруженных системах. Транзакции особенно распределенные реализуются на всех слоях информационной системы, а не только транзакциями СУБД.
Postgres Pro?) Да ладно) с учетом того, что описанные "костыли"(то есть приклад не из коробки в данном случае) все равно будут использоваться... и насколько лучше про чем свободный постгрес - еще вопрос...
@@Алексей-м7ц7й , думаете они взяли открытый постгресс и немного добавили фич, которые невсегда стабильно работают как описано в доке, затем поменяв наклейку с постгресс на постгресс про и зарегистрировали как российское ПО?)
На самом деле такое сплошь и рядом-берут опен соурс+добавляют чего-то небольшое=российский софт, а потом идут и говорят, что он может заменить западные аналоги. Хотя сами же слизали с западного ПО)
@@КоддШредингерр вы, конечно, правы, и так происходит часто, но я не считаю это главной проблемой слона. В данном случае слон из коробки - ограниченное ПО, и для указанных решений в любом случае требует других применения других программных продуктов, в отличии от mssql и oracle
@@Алексей-м7ц7й , соглашусь.
Приходится много чего допиливать или брать стороннее
Со слов "мы полностью расположены в Amazon-е" можно закрывать...
@@alex-0x6b Ну, подумайте сами.
@@alex-0x6b Ну, считайте, коль нравится и так думкаете.
@@SimargL_IncognitO Токсик
Ого, шардирование на уровне кода, connection manager, отсутствие транзакций между шардами, асинхронная репликация (диски в AWS тоже могут биться, ага, посмотрим как асинхронно восстановитесь), сторонний failover через Consul + patroni. Просто тонна денег и сил влито. Есть куда более адекватные замены PostgreSQL, которые делают все это из коробки. Посмотрите в сторону CockroachDB, сэкономите кучу денег и сил.
CockroachDB (NOSQL) энтерпрайс тоже денег просит за сапппорт и фитчи. И сколько денег тайна. У вас есть информация про то, сколько стоит решение уровня энтерпрайс? (название выбрали еще то таракан). Реактивные драйвера под CockroachDB? В чем ее преимущества реальные (не на картинках) перед MongoDB? И интересно сколько стоит найти спеца по CockroachDB на саппорт и много ли таких спецов в РФ. Раньше все пищали про то, что постгре нет спецов (в отличие от оракла), теперь тоже самое говорят про NoSQL. Вы попробуйте такое решение в энтерпрайзе защитить и обосновать. Тут PostgreSQL который обвешан сертификатами ФСТЭК смотрится выгоднее на фоне конкурентов. Я к поклноникам PostgreSQL себя не отношу, но такова реальность
@@namefn3492 порядка 80$ в месяц стоит 1 нода в cockroach cloud (GCP us-west2, 2 vCPU, 60GB). не очень понял почему они nosql - уже года 3 как реляционная база
Кластер где есть мастер не может быть отказоустойчивым, потому что перевыбор мастера занимает время.
"Мы переезжаем, будем ещё долго переезжать..."
А чем вы "умники" думали, когда код исходный писали?!
полтора года переезд внушает, "перенесли небольшую часть данных" и будем еще полтора года переезжать. мне нравится честность докладчика. инстансы редиса стали неожиданно давать лайтанси большую. была nosql bd (+in memory) и вдруг поехали на SQL БД с требованием низкое лэйтанси (странное решение). Пока не понимаю почему туже монгу не выбрали, тем более живут в клауде. Потсгре вообще большое число коннектов сам по себе без сторонних решений выдерживать не может по дефолту, что уже на мысли толкать должно. Шардирование на уровне логики приложения, то есть в коде (без комментариев).
На доработках больше работы и денег можно заработать больше, чем на perpetum mobile "под ключ"
@@namefn3492 про монго смешно. С каких пор монга начала быстро работать на чтение?)