Comments 23
Чуваки из Digg вообще прогрессивные красавцы, уже давно слежу за их нововведениями и решениями.
Кассандра сильная вещь, надо будет в продакшене попробывать.
Ага, попробыйте.
Попробывал.
1. Нагрузку на слабых машинах не держит.
2. Supercolumn Penalty, про которое я не нашел в статье ( а выделить это надо было красными буквами) Привело к тому, что касси гоняла от HDD до оперативы по 2-3 гб в нагруженных участках.
3. Переписывание на колонки не помогло — нагрузка спала на 30-40% ( т.е. с 40,8 до 34,5) Но все равно нас это не спасло.
4. Касссандра — сидльное решение для сильных кластеров. На своем корпоративном CoreQuad, на котором еще крутятся и Ваши интранетовые вещи тестировать не советую.
Например, на канале #cassandra средняя конфигурация, где ее используют — 8-ми нодовый, 16 ядер на нод и по 4 HDD на RAID1. Если Вы собираетесь масштабировать такие мощности, то «тормознутость» касси уходит на второй план, т.к. масштабировать ее очень легко — и в случае большого числа реплик работает она просто отлично, но ее привычка гонять от оперативы до жесткого неимоверные количества данных просто раздражают.
1. Нагрузку на слабых машинах не держит.
2. Supercolumn Penalty, про которое я не нашел в статье ( а выделить это надо было красными буквами) Привело к тому, что касси гоняла от HDD до оперативы по 2-3 гб в нагруженных участках.
3. Переписывание на колонки не помогло — нагрузка спала на 30-40% ( т.е. с 40,8 до 34,5) Но все равно нас это не спасло.
4. Касссандра — сидльное решение для сильных кластеров. На своем корпоративном CoreQuad, на котором еще крутятся и Ваши интранетовые вещи тестировать не советую.
Например, на канале #cassandra средняя конфигурация, где ее используют — 8-ми нодовый, 16 ядер на нод и по 4 HDD на RAID1. Если Вы собираетесь масштабировать такие мощности, то «тормознутость» касси уходит на второй план, т.к. масштабировать ее очень легко — и в случае большого числа реплик работает она просто отлично, но ее привычка гонять от оперативы до жесткого неимоверные количества данных просто раздражают.
По смыслу идея аналогична той, что используется гуглом в его Datastore для App Engine: code.google.com/appengine/docs/python/datastore/
Терминология только отличается.
А за перевод спасибо — взгляд несколько с другой стороны был полезен.
Терминология только отличается.
А за перевод спасибо — взгляд несколько с другой стороны был полезен.
Всегда пожалуйста =)
Думаю, что различия есть, вот навскидку, например, «Интерфейс хранилища данных обладает большинством функций обычных баз данных». В Cassandra это уж точно не так, и думаю, других различий множество.
Что лучше, а что хуже — этого я сказать не могу, но могу упомянуть, что Cassandra, по моим сведениям, используется на фейсбуке и в твиттере.
Думаю, что различия есть, вот навскидку, например, «Интерфейс хранилища данных обладает большинством функций обычных баз данных». В Cassandra это уж точно не так, и думаю, других различий множество.
Что лучше, а что хуже — этого я сказать не могу, но могу упомянуть, что Cassandra, по моим сведениям, используется на фейсбуке и в твиттере.
Ну это Google слегка покривил душой, чтобы не очень пугать народ, который отважится что-то писать под GAE ;)
На самом деле там есть настоящий «язык» запросов:
code.google.com/appengine/docs/python/datastore/queryclass.html#Query_filter
и есть надстройка над ним, которая называется GQL:
code.google.com/appengine/docs/python/datastore/gqlreference.html
GQL похож на SQL чисто условно. Скажем SELECT там всегда «SELECT *», естественно никаких JOIN'ов, COUNT'ов и т.п, в WHERE разрешен фактически только AND и IN, и много-много других ограничений диктуемых принципом хранения и выборки.
Я, ради любопытства, написал под GAE одно небольшое приложение. Это конечно возможно, но подходы принципиально другие. Навыки работы с реляционными базами оказываются скорее вредны, об огромном количестве вещей надо волноваться заранее — потом уже ничего не изменишь. Хочется статистики — изволь вести все необходимые счётчики в процессе записи данных. Короче говоря, есть области применений, куда эти реляционные БД удачно вписываются, но их не так много, по ощущениям.
В фейсбуке mysql, а в твиттере (погуглив) — да, пишут что вроде собираются переходить на cassandra'у.
Но в твиттере-то структура базы не такая сложная, а вот фейсбуку уйти от реляционных баз будет ой как не просто. Особенно с его любовью к громоздким страничкам с кучей разной взаимосвязанной информации из БД.
На самом деле там есть настоящий «язык» запросов:
code.google.com/appengine/docs/python/datastore/queryclass.html#Query_filter
и есть надстройка над ним, которая называется GQL:
code.google.com/appengine/docs/python/datastore/gqlreference.html
GQL похож на SQL чисто условно. Скажем SELECT там всегда «SELECT *», естественно никаких JOIN'ов, COUNT'ов и т.п, в WHERE разрешен фактически только AND и IN, и много-много других ограничений диктуемых принципом хранения и выборки.
Я, ради любопытства, написал под GAE одно небольшое приложение. Это конечно возможно, но подходы принципиально другие. Навыки работы с реляционными базами оказываются скорее вредны, об огромном количестве вещей надо волноваться заранее — потом уже ничего не изменишь. Хочется статистики — изволь вести все необходимые счётчики в процессе записи данных. Короче говоря, есть области применений, куда эти реляционные БД удачно вписываются, но их не так много, по ощущениям.
В фейсбуке mysql, а в твиттере (погуглив) — да, пишут что вроде собираются переходить на cassandra'у.
Но в твиттере-то структура базы не такая сложная, а вот фейсбуку уйти от реляционных баз будет ой как не просто. Особенно с его любовью к громоздким страничкам с кучей разной взаимосвязанной информации из БД.
Одна тонкость про фейсбук: именно они авторы Касандры
А можете прислать пруфлинк? Я за 3 минуты гугления не нашел никаких ссылок на то, что фейсбук разрабатывал кассандру.
Я буду читать комменты до конца
На всякий случай — en.wikipedia.org/wiki/Apache_Cassandra#History
Взаимосвязанную информацию в кассандре организовать можно, и очень хорошо… если вы читали статью, могли бы заметить =) другое дело, что выборок делается очень много, в MySQL информацию можно забрать парой запросов, тогда как в кассандре придётся множество записей выбирать поштучно. Но на больших проектах кассандра всё равно выигрывает у MySQL за счёт неограниченной горизонтальной масштабируемости. Насчёт других баз данных сложно сказать, я с ними не работал.
И насчёт фейсбука splix прав, у меня просто нет пруфлинка.
И насчёт фейсбука splix прав, у меня просто нет пруфлинка.
github.com/facebook/cassandra на всякий случай. Она на Java оказывается
В фейсбуке cassandra используется только для поиска по личных сообщениях. А что-то ещё они вроде как и не собираются переводить на неё.
Немного дополню. В твиттере, если верить статье на highscalability, Cassandra используется для геолокации и аналитики. Переходить на хранение твитов в кассандре они пока не решились.
Ryan King says: This is a change in strategy. Instead we’re going to continue to maintain our existing Mysql-based storage. We believe that this isn’t the time to make large scale migration to a new technology.
Пару недель назад в список рассылки разработчиков вошёл некий bikeshed с предложением полностью новой схемы именования для разрешения неразберихи.
Пару недель назад в списке рассылки разработчиков шёл процесс bikeshed-а на тему полностью новой схемы именования для разрешения неразберихи.
Такое ощущение что писали для дибилов… об элементарных вещах пишут так как будто это Квантовая механика для домохозяек.
Замечательное введение.
Проектируй я рассматриваемую схему, я бы точно вместо «волшебного значения»
Проектируй я рассматриваемую схему, я бы точно вместо «волшебного значения»
"__notag__" использовал пустую строку: и нагляднее суть «тэга нет», и места не занимает.Sign up to leave a comment.
WTF is a SuperColumn? Введение в модель данных Cassandra