Идеологически оба как раз разные. hbase работает по модели single-master. То есть в каждый момент времени есть 1 нода, овечающая за каждый регион ключей ( она так и называется — region master). Соотвественно при потере этой нода начинает происходить failover. Во время failover данные региона невозможно ни читать ни писать.
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.
Святая простота. Кто-то что-то взял… где-то попробовал, оно зачем-то до сих пор работает. Где-то… Короче, хорошее хранилище.
Если внимательно прочитать текст, то видно, что речь шла о конкретно версии 1.2. а так — хранилище неплохое, широко используются версии 0.6 и 2.0 ( сильно перепиленные для того чтобы работало хорошо ), общее число порядка 1000 нод ( в разных кластерах ).
Одноклассники — первая социальная сеть по просмотрам видео в рунете — 350 млн в сутки, а общая длительность просмотров увеличилась на 63%. Одним из важнейших запусков прошлого года стало приложение OK Live, которое стало популярным не только в России, но и в США, Германии, Украине, Турции и странах СНГ. Каждые сутки в приложении создается 40 тысяч новых трансляций, которые набирают 4 млн просмотров.
Балансировщик на балансировщике и балансировщиком погоняет, а по итогу сервис падает от сгоревшего кабеля и сорванной крыши в дата-центре.
Если внимательно прочитать текст, то становится ясно, что данные аварии приведены как пример того, почему Ок поставили себе цель выживать при потере ДЦ. Это давние случаи. По результатам же реализации этой цели сервис не падает при отказе ДЦ. Например, последний отказ был на прошлой неделе, например — расплавился автомат, возник пожар. Сервис работал штатно — пользователи ничего не заметили.
По ДЦ — в Москве они все потому что их так проще обслуживать, географическая близость их улучшает времена ответа при коммуникации — что важно при больших нагрузках. Для ускорения доступа клиентов по географии имеется CDN.
Иметь 20 ДЦ для обеспечения надежности не имеет смысла, дорого, медленно. 3 нам вполне хватает.
Я к тому, что у нас технический руководитель сам обязательно должен быть квалифицированным специалистом, который сам прекрасно понимает и разбирается в тех задачах, которые делает его команда. Не занимаясь самому техникой поддерживать квалификацию на высоком уровне практически невозможно — приблизительно через год все навыки будут утеряны и человек перестанет быть техническим руководителем — и останется просто менеджером.
Кстати, это не статья — а интервью в перерыве между докладами на хайлоаде. Про что спросили — про то Андрей и ответил.
Вот тут можно посмотреть про общую архитектуру. Первая часть практически полностью посвящена ей в тч в разрезе типичных проблем при работе с нагрузкой и отказоустойчивостью.
Если бы они делали 50 запросов, то мест бы в ДЦ не хватило.
Предположу, что вас интересуют REST API сервера. В данный момент эта группировка смотрю недонагружена — около 20% от номинальной мощности используется ( потихоньку готовимся к новому году ). Приблизительно 1000 запросов в сек обслуживает каждый.
дада, таких. вы ленту видели в социальных сетях? только в ней есть и фильтрация и сортировка и ранжирование и группировка, причем на данных которые поступают приблизительно со скоростью миллион записей в секунду.
слонов с китами сравнивать, конечно, не надо, но я привел цифры чтобы вы не слишком переоценивали свои силы в борьбе с гуглом ;-)
Ваши секреты ничего не стоят. вот тут результаты воспроизводимых тестов БЕЗ файловых кешей с чистой бизнес логикой. Как видно до 500 запросов в сек — это ближе к концу списка.
Ну и чтобы вы немножко ориентировалиcь в масштабах — за конкретно ВК не скажу, ибо просто не знаю, но в ОК таких запросов БЕЗ файловых кешей — чистой бизнес логики — около 600 000 ( шестьсот тысяч ) в секунду.
Это в принципе тема отдельной статьи. Есть немного информации тут: Распределенные системы в Одноклассниках. Немного, но больше чем можно уместить в коммент.
ок вполне считают деньги. Поэтому красотой приграничных областей и с интересом тратить время на сомнительную экономию при эксплуатации системы на режиме без запаса мощности — не занимаемся. Такой подход чреват потерей гораздо большего количества денег изза отказов, вызванных флюктуациями поведения пользователей и партнеров. Для нас более важна отказоустойчивость всей системы и ее доступность, чем экономия десятка серверов.
Все таки практика эксплуатации вполне предсказуемых расчетных задач и большой социальной сети, работающей с реальными людьми — разные вещи.
Над повышением утилизации тоже работаем, но естественно не так. Но это тема отдельной статьи.
Для абстрактной ИТ системы — возможно. Думаю тут сильно зависит от того, насколько линейно масштабируется система. В случае ок.ру — вполне себе линейно, поэтому линейного прогноза в принципе хватает.
Конечно, и такую систему можно довести нагрузкой до нелинейного деградирования, но этот самый описанный в статье capacity planning и призван своевременно увеличивать мощности, чтобы удержать систему на номинальной нагрузке и, как следствие, линейном участке. Собсно поэтому линейного прогноза вполне хватает.
Главная тема про jigsaw имхо не раскрыта — какие фичи он дает разработчикам программ на java? Очевидно, что если мне зачем-то (зачем?) захочется распилить программу на модули смогу это сделать еще и через jigsaw.
OSGi правда для этой цели есть давно, по его популярности нельзя сказать что желание распилисть что то на модули возникает у многих.
И еще страньше то, что эту тему старательно обходят все, говорящие о jigsaw. прямо заговор какой то.
и первый и второй случаи сильно похожи на баги. стоит завести тикеты у них в джире, если вы еще не завели. DateTieredCompactionStrategy правда заменяется сейчас на TimeWindowCompactionStrategy, но все равно возможно пофиксят или по крайней мере не перенесут ошибочный getNow в новый код.
Тестировать hello world почти всегда бессмысленно. Но вот результаты правильно поставленных тестов сериализации JSON. как видно решения на Java занимает 2 место, сразу после C, различные решения на Java занимают 6 позиций из 10 в топе.
Если у вас что то не получилось, возможно, вы что то делали неправильно.
У Java более высокий порог вхождения, чем у, условно, PHP. Это имеет свои и положительные и отрицательные стороны, конечно.
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.
Если внимательно прочитать текст, то видно, что речь шла о конкретно версии 1.2. а так — хранилище неплохое, широко используются версии 0.6 и 2.0 ( сильно перепиленные для того чтобы работало хорошо ), общее число порядка 1000 нод ( в разных кластерах ).
Источник:
Бизнес-завтрак Одноклассников, февраль 2017
Если внимательно прочитать текст, то становится ясно, что данные аварии приведены как пример того, почему Ок поставили себе цель выживать при потере ДЦ. Это давние случаи. По результатам же реализации этой цели сервис не падает при отказе ДЦ. Например, последний отказ был на прошлой неделе, например — расплавился автомат, возник пожар. Сервис работал штатно — пользователи ничего не заметили.
По ДЦ — в Москве они все потому что их так проще обслуживать, географическая близость их улучшает времена ответа при коммуникации — что важно при больших нагрузках. Для ускорения доступа клиентов по географии имеется CDN.
Иметь 20 ДЦ для обеспечения надежности не имеет смысла, дорого, медленно. 3 нам вполне хватает.
Кстати, это не статья — а интервью в перерыве между докладами на хайлоаде. Про что спросили — про то Андрей и ответил.
Предположу, что вас интересуют REST API сервера. В данный момент эта группировка смотрю недонагружена — около 20% от номинальной мощности используется ( потихоньку готовимся к новому году ). Приблизительно 1000 запросов в сек обслуживает каждый.
слонов с китами сравнивать, конечно, не надо, но я привел цифры чтобы вы не слишком переоценивали свои силы в борьбе с гуглом ;-)
Ну и чтобы вы немножко ориентировалиcь в масштабах — за конкретно ВК не скажу, ибо просто не знаю, но в ОК таких запросов БЕЗ файловых кешей — чистой бизнес логики — около 600 000 ( шестьсот тысяч ) в секунду.
Все таки практика эксплуатации вполне предсказуемых расчетных задач и большой социальной сети, работающей с реальными людьми — разные вещи.
Над повышением утилизации тоже работаем, но естественно не так. Но это тема отдельной статьи.
Конечно, и такую систему можно довести нагрузкой до нелинейного деградирования, но этот самый описанный в статье capacity planning и призван своевременно увеличивать мощности, чтобы удержать систему на номинальной нагрузке и, как следствие, линейном участке. Собсно поэтому линейного прогноза вполне хватает.
OSGi правда для этой цели есть давно, по его популярности нельзя сказать что желание распилисть что то на модули возникает у многих.
И еще страньше то, что эту тему старательно обходят все, говорящие о jigsaw. прямо заговор какой то.
Если у вас что то не получилось, возможно, вы что то делали неправильно.
У Java более высокий порог вхождения, чем у, условно, PHP. Это имеет свои и положительные и отрицательные стороны, конечно.