Во время моего первого опыта работы с распределенными системами я постоянно сталкивался с некой CAP-теоремой, пришлось изрядно покопать, чтобы изучить и осознать её со всех сторон. Я не являюсь мастером баз данных, но надеюсь, что мое маленькое исследование мира распределённых систем будет полезно для обычных разработчиков. В статье я расскажу о том, что такое CAP, его проблемы и альтернативы, а также рассмотрим некоторые популярные системы баз данных через CAP призму.
Читать полностью »
Рубрика «cassandra» - 3
Всё, что вы не знали о CAP теореме
2017-05-16 в 11:28, admin, рубрики: acid, base, cap, cassandra, mongodb, nosql, pacelc, postgresql, Анализ и проектирование систем, архитектура, базы данных, проектирование, проектирование баз данных, распределенные системыЧасть 3. Где хранить данные децентрализованным приложениям на блокчейне?
2017-05-04 в 10:51, admin, рубрики: big data, blockchain, byzantine fault tolerance, cassandra, elassandra, elasticsearch, Ethereum, nosql, open source, Анализ и проектирование систем, базы данных, блокчейн, децентрализация, децентрализованные сети, концепт, криптография, мотивация, хранение данных, хранилище данныхВ первой части статьи мы обнаружили проблемы с хранением данных приложений в блокчейне. Во второй части мы описали требования к хранилищу данных и рассмотрели, насколько существующие реализации отвечают этим требованиям. Результаты были неутешительные — удовлетворительной реализации не нашлось. В данной части мы предложим концепцию децентрализованного хранилища данных, которое удовлетворяет поставленным требованиям. Разумеется, для более глубокого понимания сути происходящего рекомендуется просмотреть две предыдущие части.
Читать полностью »
Инфраструктура Twitter: масштаб
2017-03-30 в 13:03, admin, рубрики: BGP, Blobstore, cassandra, Clos, FlockDB, Gizzard, graph, Hadoop, Haplo, Manhattan, memcache, mesos, MPLS, mysql, Nighthawk, puppet, redis, RSVP, Snowflake, twitter, twitter api, высокая производительность, инфраструктура, Проектирование и рефакторинг, Системы обмена сообщениямиОбзор парка Twitter
Twitter пришёл из эпохи, когда в дата-центрах было принято устанавливать оборудование от специализированных производителей. С тех пор мы непрерывно разрабатывали и обновляли серверный парк, стремясь извлечь пользу из последних открытых технологических стандартов, а также повысить эффективность работы оборудования, чтобы обеспечить наилучший опыт для пользователей.
Наше текущее распределение оборудования показано ниже:
Вероятность потери данных в больших кластерах
2017-03-29 в 20:40, admin, рубрики: cassandra, hdfs, mongodb, riak, Администрирование баз данных, кластер, математика, потеря данных, Серверное администрирование, хранение данных, хранилища данныхВ этой статье используется MathJax для рендеринга математических формул. Нужно включить JavaScript, чтобы MathJax заработал.
Многие распределённые системы хранения (в том числе Cassandra, Riak, HDFS, MongoDB, Kafka, …) используют репликацию для сохранности данных. Их обычно разворачивают в конфигурации «просто пачка дисков» (Just a bunch of disks, JBOD) — вот так, без всякого RAID для обработки сбоев. Если один из дисков в ноде отказывает, то данные этого диска просто теряются. Чтобы предотвратить безвозвратную потерю данных, СУБД хранит копию (реплику) данных где-то на дисках в другой ноде.
Самым распространённым фактором репликации является 3 — это значит, что база данных хранит три копии каждого фрагмента данных на разных дисках, подключенных к трём разным компьютерам. Объяснение этому примерно такое: диски выходят из строя редко. Если диск вышел из строя, то есть время заменить его, и в это время у вас ещё две копии, с которых можно восстановить данные на новый диск. Риск выхода из строя второго диска, пока вы восстанавливаете первый, достаточно низок, а вероятность смерти всех трёх дисков одновременно настолько мала, что более вероятно погибнуть от попадания астероида.
Читать полностью »
Как Discord индексирует миллиарды сообщений
2017-03-27 в 8:17, admin, рубрики: cassandra, Discord, elasticsearch, Google Cloud Platform, lucene, open source, redis, solr, Анализ и проектирование систем, высокая производительность, Системы обмена сообщениями, метки: Discord
Миллионы пользователей ежемесячно отправляют миллиарды сообщений в Discord. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!
Требования
- Экономически эффективный: Основное взаимодействие пользователя с Discord — это наш текстовый и голосовой чат. Поиск — вспомогательная функция, и стоимость инфраструктуры должна отражать это. В идеале это значит, что поиск не должен стоить дороже, чем фактическое хранение сообщений.
- Быстрый и интуитивно понятный: Все создаваемые нами функции должны быть быстрыми и интуитивными, в том числе поиск. Он должен выглядеть и ощущаться по высшему стандарту.
- Самовосстановление: У нас нет отдела DevOps (пока), так что поиск должен выдерживать сбои с минимальным человеческим вмешательством или вообще без него.
- Линейно масштабируемый: Как и с хранением сообщений, увеличение ёмкости поисковой инфраструктуры должно предусматривать добавление нодов.
- Ленивая индексация: Не все пользуются поиском — мы не должны индексировать сообщения, пока кто-то не попытается хотя бы раз их найти. Вдобавок, после сбоя индекса должна быть возможность переиндексации серверов на лету.
Как Discord хранит миллиарды сообщений
2017-03-11 в 13:19, admin, рубрики: cassandra, Discord, mongodb, Scylla, высокая производительность, Системы обмена сообщениями, СУБД, Тестирование веб-сервисов
Discord продолжает расти быстрее, чем мы ожидали, как и пользовательский контент. Чем больше пользователей — тем больше сообщений в чате. В июле мы объявили о 40 млн сообщений в день, в декабре объявили о 100 млн, а в середине января преодолели 120 млн. Мы сразу решили хранить историю чатов вечно, так что пользователи могут вернуться в любой момент и получить доступ к своим данным с любого устройства. Это много данных, поток и объём которых нарастает, и все они должны быть доступными. Как мы это делаем? Cassandra!
Читать полностью »
Введение в CDRS, Cassandra driver полностью написанный на Rust
2017-02-10 в 12:39, admin, рубрики: cassandra, CQL, RustCDRS (Cassandra driver written in Rust) — это мой собственный open source проект, который я решился разрабатывать после того, как обнаружил, что в плане драйверов для Cassandra в Rust экосистеме образовался дефицит.Читать полностью »
Как мы неделю чинили compaction в Cassandra
2016-09-17 в 6:11, admin, рубрики: cassandra, devops, nosql, troubleshooting, Блог компании okmeter.io, системное администрирование, хранение данных
Основным хранилищем метрик у нас является cassandra, мы используем её уже более трех лет. Для всех предыдущих проблем мы успешно находили решение, используя встроенные средства диагностики кассандры.
В кассандре достаточно информативное логгирование (особенно на уровне DEBUG, который можно включить на лету), подробные метрики, доступные через JMX и богатый набор утилит (nodetool, sstable*).
Но недавно мы столкнулись с одной достаточно интересной проблемой, и нам пришлось серьезно поломать голову, почитать исходный код кассандры, чтобы разобраться, что происходит.
Интервью с Сергеем Лукьяновым, техническим лидером проекта OpenStack Savanna
2014-02-25 в 10:08, admin, рубрики: cassandra, diablo, gerrit, hacking, Hadoop, heat, Jeepyb, Nova client, open source, openstack, Oslo, Pbr, swift, Twitter Storm, Блог компании Mirantis/OpenStack, мирантисБеседовал Рафаэль Кнут (Rafael Knuth)
Представляем вам 10-е интервью из серии бесед с техническими руководителями проектов инициативы OpenStack в блоге Mirantis. Наша цель – обучение как можно большего числа членов технического сообщества и содействие понимаю того, каким образом можно внести вклад в OpenStack и как извлечь выгоду из него. Разумеется, ниже изложена точка зрения интервьюируемого, а не компании Mirantis.Читать полностью »
В Екатеринбурге завершилась Cassandra conf
2013-12-23 в 11:43, admin, рубрики: big data, cassandra, it-people, nosql, Блог компании IT-People, екатеринбург, конференция, метки: cassandra, it-people, екатеринбург, конференция9 декабря в Екатеринбурге прошла первая в России конференция, посвященная NoSQL-системе Cassandra. Организаторами конференции выступили компании IT-People, СКБ Контур и DataStax. Поддержку мероприятию оказало Министерство транспорта и связи Свердловской области.