Комментарии 25
Спасибо за статью. Взяли на заметку.
Насчет Tarantool: на какой-то презентации обещали завезти поддержку SQL.
Насчет Tarantool: на какой-то презентации обещали завезти поддержку SQL.
А вы кстати на TiDB не смотрели? Это очень похожее на cockroachdb что-то, судя по тому, что я могу видеть
Что вы думаете по поводу in-memory data grid (напр., де-факто отечественный gridgain.com)?
В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей. Распределение нагрузки по такому ключу рано или поздно приведет к переполнению одних серверов в кластере и недозагруженности других. В этот момент потребуется ребалансировка — то есть разделение ноды кластера на две. Эту работу сложно делать на работающем 24x7 кластере без потери надежности.
1) Я правильно понял вашу мысль, что вы отказались от PostgreSQL из-за того, что попытались использовать неподходящий для вас алгоритм генерации ключа шардирования? Если шардировать по компании вы не можете, можно же использовать что-то иное.
2) CockroachDB как-то пока не выглядит production ready — habrahabr.ru/post/345990
1) Не совсем. Сложно предсказать характер нагрузки через несколько лет. Поэтому какой бы алгоритм шардирования ни выбрать, рано или поздно придется делать ребалансировку. Хочется выбрать БД, которая умеет делать ребалансировку (менять алгоритм шардирования и соответственно переносить данные) на лету. Если таких не найдется или они будут недостаточно надежны в production — придется вернуться к mySQL/PostreSQL.
2) Мы делаем ставку на то, что он станет production ready в обозримое время (в ближайший год, например). Это осознанный риск, который мы можем себе позволить — мы никуда не торопимся. А статья скорее повышает доверие к нему — ведь про многие альтернативы аналогичных статей «как я восстановил данные» — не находится.
2) Мы делаем ставку на то, что он станет production ready в обозримое время (в ближайший год, например). Это осознанный риск, который мы можем себе позволить — мы никуда не торопимся. А статья скорее повышает доверие к нему — ведь про многие альтернативы аналогичных статей «как я восстановил данные» — не находится.
Простите, очень странное сравнение баз данных и критерии выбора… на пальцах как-то все.
— тут не понятно, имеется ввиду трафик? Если объем сохраняемых данных — опять не понятно, данные взяты абсолютно, или с учетом всех кластеров\репликаций и т.п.?
— если, предположить, данные указаны в пределах одного экземпляра БД (мастер-кластера в идеале), получается: 60Гб * 30дней * 12мес = 21,6 Тб, не учитывая потенциальный рост компании, и умножить, к примеру, на х6 (2 мастера, по два слейва на мастер) — 129,6Тб в год, за 10 лет ~1.3Пб… впечатляющий объем.
самое любопытное — не сказано как сейчас у вас устроено хранение… опять все на пальцах.
Слишком легкомысленный подход к выбору технологий, как для заявленных объемов.
Простите, не ясно что за БД у вас используется, но тот-же mysql при грамотной архитектуре приложения и бд, без проблем справится с тесятками-сотнями тысяч пользователей, проблема больших и маленьких шардов странная
у нас в компании, для статистики, собирается много данных, каждуй минуту сотни записей с 1 устройства, за день со всех устройств (около 800) — десятки тысяч записей, в результате — самая большая таблица: ~450млн.записей, + несколько таблиц от 1млн до 10млн записей, все крутиться на 1 сервере, одна бд мускл, ниче не тормозит, запросы ходят хорошо, запросы которые начинали выполняться долго — оптимизировали, избавляясь от join и т.п., разбивая получения данных вместо 1 сложного запроса — на несколько простых…
Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно.
— тут не понятно, имеется ввиду трафик? Если объем сохраняемых данных — опять не понятно, данные взяты абсолютно, или с учетом всех кластеров\репликаций и т.п.?
— если, предположить, данные указаны в пределах одного экземпляра БД (мастер-кластера в идеале), получается: 60Гб * 30дней * 12мес = 21,6 Тб, не учитывая потенциальный рост компании, и умножить, к примеру, на х6 (2 мастера, по два слейва на мастер) — 129,6Тб в год, за 10 лет ~1.3Пб… впечатляющий объем.
самое любопытное — не сказано как сейчас у вас устроено хранение… опять все на пальцах.
Слишком легкомысленный подход к выбору технологий, как для заявленных объемов.
В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей.
Простите, не ясно что за БД у вас используется, но тот-же mysql при грамотной архитектуре приложения и бд, без проблем справится с тесятками-сотнями тысяч пользователей, проблема больших и маленьких шардов странная
у нас в компании, для статистики, собирается много данных, каждуй минуту сотни записей с 1 устройства, за день со всех устройств (около 800) — десятки тысяч записей, в результате — самая большая таблица: ~450млн.записей, + несколько таблиц от 1млн до 10млн записей, все крутиться на 1 сервере, одна бд мускл, ниче не тормозит, запросы ходят хорошо, запросы которые начинали выполняться долго — оптимизировали, избавляясь от join и т.п., разбивая получения данных вместо 1 сложного запроса — на несколько простых…
Спасибо за комментарий. Подробно описать нашу инфраструктуру — тема отдельного поста, но вкратце отвечая на ваши вопросы:
60GB — абсолютный объем новых данных, которые нужно ежедневно сохранять (в рабочий день, в выходные поменьше). Бывают пики до 1GB/минуту. Большая часть — неструктурированные данные, которые хранятся отдельно от БД.
В самой крупной таблице около 300 млн записей, и при текущих объемах все вполне может жить в рамках одного мастер-сервера с несколькими репликациями. И, с учетом роста нагрузки, в пределах 12-24 мес тоже будет жить. Скорость хорошая — большинство запросов к БД работают in memory, на application servers — логические кеши, у фронтового nginx — свой кеш.
Но рано или поздно структурированные данные перестанут влезать в одну машину и нужно заранее к этому подготовиться. Поэтому сейчас начнем писать все данные в две базы одновременно и посмотрим, насколько надежно работает выбранный CockroachDB.
Если в течение 3-4 мес все будет без сбоев — начнем потихоньку отключать текущую БД. А если вдруг уровень надежности будет недостаточным — сделаем на PostgreSQL, благо разработчики CockroachDB взяли его диалект для своего языка запросов.
Согласен, любую задачу шардинга можно решить на mysql/postgresql. Но если ее уже за нас решили разработчики БД, включая автоматическую ребалансировку и восстановление при сбоях, и это работает надежно, почему бы этим не воспользоваться?
60GB — абсолютный объем новых данных, которые нужно ежедневно сохранять (в рабочий день, в выходные поменьше). Бывают пики до 1GB/минуту. Большая часть — неструктурированные данные, которые хранятся отдельно от БД.
В самой крупной таблице около 300 млн записей, и при текущих объемах все вполне может жить в рамках одного мастер-сервера с несколькими репликациями. И, с учетом роста нагрузки, в пределах 12-24 мес тоже будет жить. Скорость хорошая — большинство запросов к БД работают in memory, на application servers — логические кеши, у фронтового nginx — свой кеш.
Но рано или поздно структурированные данные перестанут влезать в одну машину и нужно заранее к этому подготовиться. Поэтому сейчас начнем писать все данные в две базы одновременно и посмотрим, насколько надежно работает выбранный CockroachDB.
Если в течение 3-4 мес все будет без сбоев — начнем потихоньку отключать текущую БД. А если вдруг уровень надежности будет недостаточным — сделаем на PostgreSQL, благо разработчики CockroachDB взяли его диалект для своего языка запросов.
Согласен, любую задачу шардинга можно решить на mysql/postgresql. Но если ее уже за нас решили разработчики БД, включая автоматическую ребалансировку и восстановление при сбоях, и это работает надежно, почему бы этим не воспользоваться?
спасибо, немного прояснилось,
пожалуй соглашусь: с большой БД самое страшное, когда что-то пошло не так и слейв сломался, или шард или еще что-то… поведение БД в подобных ситуациях, по моему, лишь практически удастся оценить, в теории всегда все гладко и предсказуемо :)
пожалуй соглашусь: с большой БД самое страшное, когда что-то пошло не так и слейв сломался, или шард или еще что-то… поведение БД в подобных ситуациях, по моему, лишь практически удастся оценить, в теории всегда все гладко и предсказуемо :)
Более того, я еще не видел ни одной серьезной production-системы, из которой когда-либо не восстанавливали данные вручную. Рано или поздно сбой случится, и надо быть готовым. Спасибо коллеге youROCK, который протоптал эту дорожку для CockroachDB :)
В штуках типа CockroachDB напрягает магия. То есть шардинг то есть, но больно магический. Плюс конкретно в Cockroach печалят сильные ограничения по сравнению с Postgres, но они вроде работают над этим.
Шардинг совсем не магический. Он идет с помощью разбиения пространства ключей на диапазоны по 64 Мб. Ключи составляются как /<Таблица>/<тип>/<значение>. Для обычных записей в тип записывается 1, для индексов — 2. В значение пишется значение первичного ключа или индекса соответственно.
То есть, грубо говоря, данные шардятся по первичному ключу, а индексы — по значению индекса. Какая тут магия-то :)?
То есть, грубо говоря, данные шардятся по первичному ключу, а индексы — по значению индекса. Какая тут магия-то :)?
Lua — хотя он и популярен среди разработчиков игр, но закрытый
Кто его закрыл???
Вносить изменения в исходный код lua могут только авторы из Папского католического университета Рио-де-Жанейро.
Вносить изменения в ядро Linux кому то с улицы тоже не сразу разрешат, но оно от этого не становится закрытым
В ядро Linux за последние 30 дней внесли изменения 341 человек: https://github.com/torvalds/linux/pulse/monthly. Довольно многим разрешают.
По lua — формально вы правы, я неточно выразился. MIT лицензия — свободная лицензия.
Но когда мастер-исходники выложены на github и авторы позволяют сообществу вносить в них исправления — это более открытый подход. Мы таким образом внесли несколько патчей в продукты, которые используем, последний раз — в клиентскую библиотеку NATS.
По lua — формально вы правы, я неточно выразился. MIT лицензия — свободная лицензия.
Но когда мастер-исходники выложены на github и авторы позволяют сообществу вносить в них исправления — это более открытый подход. Мы таким образом внесли несколько патчей в продукты, которые используем, последний раз — в клиентскую библиотеку NATS.
-
Здравствуйте Pyrus,
Вы написали, что отказались от облачных решений, но не рассматривали ли Вы перед отказом Azure Cosmos DB?
Она очень заинтересовала, но информации о ней (кроме как от Microsoft) не так то и много.
Буду благодарен если поделитесь своими соображениями, если рассматривали ее.
Вы написали, что отказались от облачных решений, но не рассматривали ли Вы перед отказом Azure Cosmos DB?
Она очень заинтересовала, но информации о ней (кроме как от Microsoft) не так то и много.
Буду благодарен если поделитесь своими соображениями, если рассматривали ее.
Добрый день, мы пристально Azure Cosmos DB не рассматривали по причине сильной зависимости от одного вендора. Представьте, вдруг она перестала работать — а вам даже позвонить некуда…
Однако обещания у них заманчивые. )
Однако обещания у них заманчивые. )
Здравстувйте Pyrus,
По такой логике AWS, Azure, Digital Ocean и любым другим поставщикам облачных услуг доверять вовсе нельзя, а надо строить свои дата-центры. Но согласитель — это ведь довольно накладно и очень редко, когда оправдано.
Я с Вами не спорю, такая вероятность естественно есть. И от отказа облачного сервиса всегда надо себя обезопасить.
Вы не думали над вариантом использования облачной распределенной базы (Cosmos DB или альтернатив) с репликацией в свою собственную(в которую не сложно перенести данные из облачной, к примеру для Cosmos DB кажется наиболее близка ArangoDB) на случай экстренного восстановления?
К примеру иметь несколько серверов для репликации, которые будут использоваться в случает отказа основной базы и писать в них чем-то вроде сервисов на Go срабатывающих на CRUD операции.
Если не совсем понятно что я пытаюсь описать — могу визуализировать.
Представьте, вдруг она перестала работать — а вам даже позвонить некуда…
По такой логике AWS, Azure, Digital Ocean и любым другим поставщикам облачных услуг доверять вовсе нельзя, а надо строить свои дата-центры. Но согласитель — это ведь довольно накладно и очень редко, когда оправдано.
Я с Вами не спорю, такая вероятность естественно есть. И от отказа облачного сервиса всегда надо себя обезопасить.
Вы не думали над вариантом использования облачной распределенной базы (Cosmos DB или альтернатив) с репликацией в свою собственную(в которую не сложно перенести данные из облачной, к примеру для Cosmos DB кажется наиболее близка ArangoDB) на случай экстренного восстановления?
К примеру иметь несколько серверов для репликации, которые будут использоваться в случает отказа основной базы и писать в них чем-то вроде сервисов на Go срабатывающих на CRUD операции.
Если не совсем понятно что я пытаюсь описать — могу визуализировать.
Облачные сервисы падают регулярно, это нормально. Мы их используем, но не зависим от одного конкретного.
Использовать две разных БД — дорого. Основные затраты — на экспертизу разработчиков. Команда должна освоить обе БД в достаточной степени, чтобы обеспечить надежность и производительность.
Поэтому мы выбрали БД, которую можно развернуть в любом облаке или дата-центре.
Использовать две разных БД — дорого. Основные затраты — на экспертизу разработчиков. Команда должна освоить обе БД в достаточной степени, чтобы обеспечить надежность и производительность.
Поэтому мы выбрали БД, которую можно развернуть в любом облаке или дата-центре.
Про монгу информация устаревшая, что при падении мастера теряются данные. Вообще, с этим плохо практически у всех, тест у jepsenов заказывать стесняются. В целом непонятны муки выбора — чтобы не терять данные на импорте, писать через промежуточный кеш.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбор надежной БД в высоконагруженном проекте