M>>Именно. При том, что, повторю, ты игнорируешь гораздо более принципиальный момент о том, что масштабируются они исключительно хреново.
_>Эээ, хреново в сравнение с чем?
С решениями, которые обкатаны и работают уже много лет. NoSQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!! (за очень редким исключением вроде Riak'а)
Здравствуйте, Mamut, Вы писали:
M>>>Именно. При том, что, повторю, ты игнорируешь гораздо более принципиальный момент о том, что масштабируются они исключительно хреново. _>>Эээ, хреново в сравнение с чем? M>С решениями, которые обкатаны и работают уже много лет. NoSQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!! (за очень редким исключением вроде Riak'а)
IBM IMS масштабируется хорошо, по крайней мере ФРС не жалуется (я где-то выше уже приводил ссылку, что с точки зрения масштабирования это "почти" чемпион). В этой же области у нее есть младшие братья (типа System2k) которые стоят меньших денег (хотя использовать их довольно рискованно при любом раскладе). Другой пример — GAE Datastorage; вполне себе хорошо масштабируется (у нее там другие проблемы, которые не позволяют сделать норм. продукт, но со scalability все ок) внутри Google.
Кстати вы не поверите (недавно прочел в databasejournal) — в эпоху расцвета isam-а и начала становления sql в местных научных журналах империалистических стран загнивающего запада можно было часто прочитать такую фразу — "SQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!!". Ничего не напоминает ?
M>When sharding an existing collection, please be aware that this process will take some time... it will take quite a while for the data to migrate/balance on a large collection. For example, on a system with ten shards, 90% of the data for the collection will need to transfer to elsewhere to attain balance. Note that only large collections rebalance. If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
M>Не говоря о том, что они считают большой коллекцией что-либо больше 400 MB. Держите меня семеро.
Не, ну уж если мы решили распилить данные — то их таки придётся двигать, независимо от технологии. Чудес ведь не бывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M> AB>Тут имеется ввиду немного другое. Был кластер из одного шарда, стало 10. В итоге 90% информации из 1-го шарда "размажется" по оставшимся 9 и на исходном шарде останется 1/10 информации, которая была до добавления шардов. Это поведение вполне логично, но и его можно контролировать при желании.
M> Цитирую: M> 90% of the data for the collection will need to transfer to elsewhere to attain balance.
Да, это как раз то, о чем я писал — мы пилим 100% коллекцию на 10 кусков-шардов. Естественно, что нам придется перегнать 90% данных между серверами (по 10% на каждый и 10% останется на месте).
M> Цитирую: M> If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
Тоже разумная рекомендация, т.к. монга очень скорострельна на стандартных кейсах и шардинг маленьких коллекций может не иметь практического смысла.
Здравствуйте, Mamut, Вы писали:
_>>Эээ, хреново в сравнение с чем? M>С решениями, которые обкатаны и работают уже много лет. NoSQL-евцы переизобретают велосипеды, предлагают однобокие решения и орут, что это круто!!! (за очень редким исключением вроде Riak'а)
Ну так можно конкретно по именам? ) Какие сейчас решения применяются для масштабирования базы данных на сеть из серверов?
Здравствуйте, Sinclair, Вы писали:
ANS>>Если и так, то твоя схема с асинхронной репликой не даёт sequental гарантий. S>Ещё как даёт.
Это ты так думаешь от того, что ты смотришь на сбой /мастера/ как на апокалипис, конец времени после которого уже не важно что там в БД за данные. Но при автофайловере такой сбой превращается в норму. И вот некая система видела данные, работала с ними, а потом трах-бах и не видит. Ну и какая это консистентность?
ANS>>ACID база как бы выступает теми самыми внешними часами относительно которых всё измеряется. S>Только в том случае, если мы перед ней ставим такую задачу.
Не важно ставим или нет. ACID система работает как единое целое, что повышает требования к коммуникационным каналам между нодами.
S>>>А если страшна — то делаем синхронную репликацию и вперед. ANS>>Это то, почему я обращаю внимание именно на падение реплики. При синхронной репликации, при падении реплики вся система должна остановить работу. S>С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было.
Достаточно кворума. Т.е. получается при одном сервере его падение — катастрофа. При двух — падение слейва катастрофа. При трёх серверах для даунтайма нужно одновременное падение двух.
ANS>>Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления коннективити, данные в базах автоматически синхронизируются. ANS>>Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь траффик автоматически переключается в работающий датацентр. ANS>>И как оно работает? S>Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это ты так думаешь от того, что ты смотришь на сбой /мастера/ как на апокалипис, конец времени после которого уже не важно что там в БД за данные. Но при автофайловере такой сбой превращается в норму. И вот некая система видела данные, работала с ними, а потом трах-бах и не видит. Ну и какая это консистентность?
И тем не менее, последовательность наблюдаемых изменений будет в такой системе одинаковой.
ANS>Не важно ставим или нет. ACID система работает как единое целое, что повышает требования к коммуникационным каналам между нодами.
Нет. Это вы себе придумали зачем-то. ACID построен на понятиях сериализуемости. Требования задавать общесистемные часы у ACID нету.
S>>С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было.
ANS>Достаточно кворума. Т.е. получается при одном сервере его падение — катастрофа. При двух — падение слейва катастрофа. При трёх серверах для даунтайма нужно одновременное падение двух.
Вы опять сами себе противоречите. При двух серверах падение любого получается катастрофа — ведь останется только один сервер! Значит, система из двух серверов неотказоустойчива. Тогда и три сервера вам ничем не помогут — ведь при падении одного из них останется только два, а неотказоустойчивость этой комбинации уже доказана.
Я вам это уже в третий раз рассказываю, а вы игнорируете. Почему? Не совпадает с вашим шаблоном?
S>>Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности. ANS>Чего?
Что конкретно вам непонятно? Вам непонятно, почему уменьшается латентность? Потому что европейским клиентам быстрее сбегать в европейский датацентр, чем в северную америку. Непонятно, почему возникает неконсистентность? Потому что мы разрешаем европейским клиентам работать со своей репликой, не извещая об этом американскую реплику. Непонятно, как сохранить консистентность? Элементарно — запрещать модификации при потере связи между датацентрами, или заставлять европейских клиентов ходить в американский датацентр. Непонятно, почему ухудшится латентность? Потому, что операции записи теперь будут стоить немножко больше.
Если вам кажется, что запрет модификаций — это отказ от availability, то это тоже иллюзия. Потому, что бескомпромиссная availabilty вообще невозможна в распределённой среде. Ведь канал между серверами гораздо надёжнее канала между сервером и клиентом; а в случае падения последнего никакая избыточность на серверной стороне вас не спасёт.
Вот поэтому-то CAP-теорема и является фуфлом: рассматриваемая ею модель слишком сферическая и слишком в вакууме.
Для того, чтобы осмысленно рассуждать о нарушениях консистентности, доступности и связности, надо вводить более продвинутые модели. И сравнивать не абсолютные величины типа "есть"/"нету", а вероятности тех или иных событий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Anton Batenev, Вы писали:
M>> Цитирую: M>> If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
AB>Тоже разумная рекомендация, т.к. монга очень скорострельна на стандартных кейсах и шардинг маленьких коллекций может не иметь практического смысла.
Как бы это сказать... В общем, для современных РСУБД 400МБ это не 'small', а 'tiny'. Рекомендация разносить данные на разные сервера, если их размер меньше десятков ГБ вызывает недоумение, особенно в разрезе песнопений об экономии на железе.
Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?
Здравствуйте, _ABC_, Вы писали:
_AB>Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?
Например, в случае, если вы выбрали стратегию in-memory database, но оперируете данными более 2Гб (напр. low-latency trading). В таком случае разнесение с точки зрения уменьшения стоимости входа в эту стратегию (и возможно стоимости владения, но не факт), вам эффективнее использовать горизонтальное масштабирование (то бишь шардинг по русски ), чем вертикальное. Мог бы привести еще парочку примеров
Здравствуйте, a_g_99, Вы писали:
__>Например, в случае, если вы выбрали стратегию in-memory database, но оперируете данными более 2Гб (напр. low-latency trading). В таком случае разнесение с точки зрения уменьшения стоимости входа в эту стратегию (и возможно стоимости владения, но не факт), вам эффективнее использовать горизонтальное масштабирование (то бишь шардинг по русски ), чем вертикальное. Мог бы привести еще парочку примеров
А пример такого уменьшения стоимости можно с актуальными ценами?
И точно мы в случае с low-latency trading оперируем данными более 2ГБ? Просто это не моя предметная область.
Здравствуйте, _ABC_, Вы писали:
_AB>А пример такого уменьшения стоимости можно с актуальными ценами?
Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен). Напр. я беру стандартный HP ProLiant DL385G7 с 16Гб памятью по умолчанию (+хорошие возможности наращивания), сам сервер, если очень скромно его конфигурить (по нищебродски) обойдется в 30k + базовый софт (напр. Windows) в 2.5k. Примерный уровень цен можете посмотреть в первоисточнике. Напр. парни из TPC насчитали там на 400k в комплексе — все оборудование + весь софт. В реальной жизни, в среднем, это вам обойдется где-то в 70k.
Либо вы берете 3 машинки типа IBM ExpSell x3400 (1.5-2k), каждая с 4 Гб памяти + 4k за noname-обкладку на первом этапе. + софта на 5-7k.
Итого — 70k > 15k. Если i-mdb собственная профит очевиден. Если от мейджора надо сильно-сильно думать и считать.
_AB>И точно мы в случае с low-latency trading оперируем данными более 2ГБ? Просто это не моя предметная область.
Напр. для современных взрослых систем арбитража это базовый порог входа. Меньше конечно можно, но уже как-то несолидно , только в Бангладеше или России банчить
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, _ABC_, Вы писали:
_AB>>А пример такого уменьшения стоимости можно с актуальными ценами? __>Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен).
Вопросы:
Что такое "отмасштабироваться по взрослому"? В цифрах и фактах, пожалуйста.
_AB>>И точно мы в случае с low-latency trading оперируем данными более 2ГБ? Просто это не моя предметная область. __>Напр. для современных взрослых систем арбитража это базовый порог входа. Меньше конечно можно, но уже как-то несолидно , только в Бангладеше или России банчить
И чем определяется этот "базовый порог входа"? Вообще, применительно к объему памяти "базовый порог входа" что призван означать?
Здравствуйте, a_g_99, Вы писали: __>Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен). Напр. я беру стандартный HP ProLiant DL385G7 с 16Гб памятью по умолчанию (+хорошие возможности наращивания), сам сервер, если очень скромно его конфигурить (по нищебродски) обойдется в 30k + базовый софт (напр. Windows) в 2.5k.
Мне кажется, что вы передёргиваете. "Вертиально отмасштабироваться", при стратегии In-memory database, означает иметь приличный CPU и RAM. Могучая дисковая подсистема, в которую уходят все деньги на TPC-C, вам не нужна.
16 ядер и 24GB памяти вам обойдутся в пределах 10K. На них всё будет просто летать, т.к. никакой "нонейм обкладки" между клиентами и сервером нету. А ваши четыре-пять говномашинок, которые совместно будут тянуть распиленную на куски базу того же размера, выйдут вам (по вашим же расчётам) в пару раз дороже. Увы, чудес не бывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, a_g_99, Вы писали:
__>Да запросто. В случае если вы решили вертикально отмасштабироваться по взрослому, вам потребуется сервер уровня TPC-C — Top Ten Price/Performance Results (на просто Top Ten Performance я не замахиваюсь — там уже совсем иной уровень цен). Напр. я беру стандартный HP ProLiant DL385G7 с 16Гб памятью по умолчанию (+хорошие возможности наращивания), сам сервер, если очень скромно его конфигурить (по нищебродски) обойдется в 30k + базовый софт (напр. Windows) в 2.5k. Примерный уровень цен можете посмотреть в первоисточнике.
Поигрался с конфигуратором. С двумя топовыми процами (хотя Opteron'ы не мой выбор, но на этот сервер идут только они), 64 гигами оперативы, 4 SAS 15к 146GB и 8 SAS SSD MLC 200GB и всеми необходимыми довязками получил результат в 58 тысяч у.е.
Если совсем "по нищебродски" набивать этот сервер, то он мне обойдется не в 30к, а тысяч в 7.
__>Напр. парни из TPC насчитали там на 400k в комплексе — все оборудование + весь софт.
Парни чисто дисков накупили на 236 тысяч и стоимость владения посчитали за три года в 50 тысяч. Если стратегия выбрана in-memory db, то смысла в покупке стольки дисков немного.
Здравствуйте, _ABC_, Вы писали:
ABC> Как бы это сказать... В общем, для современных РСУБД 400МБ это не 'small', а 'tiny'.
Слушай, ну это уже придирки к словам. Tiny она или small — это исключительно зависит от наблюдателя, работающего с конкретной коллекцией, имеющегося оборудования и здравого смысла.
ABC> Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?
Зависит от конфигурации сервера(ов) и требуемой скорострельности. Поскольку mongo легко масштабируется, можно стартовать на достаточно слабых серверах (в т.ч. VPS) и легко расширяться или мигрировать на более мощное оборудование вместе с ростом нагрузки и/или финансов.
Здравствуйте, _ABC_, Вы писали:
Я попытаюсь ответить так чтобы не впадать в троллинги не цитировать кэптана Очевидность
_AB>Вопросы: _AB>Что такое "отмасштабироваться по взрослому"? В цифрах и фактах, пожалуйста.
Что такое масштабирование здесь. Я по крайней мере с тем что написано в wiki согласен.
По взрослому — это когда вам следует нарастить возможности системы выше, чем "средние" возможности подобных систем. А какие уж характеристики/цифры у средних систем, решать вам самому (количество/"вес" данных в Гб, transactions per sec, users ?). Напр. есть замечательный блогосайт highscalability там хорошо все изложено (а писать долго и лениво )
_AB>И чем определяется этот "базовый порог входа"?
Постановкой задачи или задачей в развитии. Напр. в применении к арбитражу вам ставят следующую задачу:
1) есть две разнесенные системы (два сайта, биржи, или игровые сервера — думаю не суть важно).
2) в каждой из этих систем есть идентичный по сути объект, который обладает разными характеристиками (напр ценная бумага с разной стоимостью, или книжка/диск на сайте)
3) Нужно получить данные объекта из двух систем, сравнить их и в зависимости от результата сравнения пары выполнить действие
Вы смотрите физику и видите что каждый объект весит напр. 50kb. Значит чтобы сформировать пару нужно мин. 100k (в реальности больше, т.к. там будут доп. очереди, буферы и т.д.). Итого 10 пар = 1Мб, 10k пар 1 Гб, 100k пар — 10Гб. Издержки обработки должны быть минимальны (у нас же low latency в теории ). Таким образом вы можете прикинуть мин. требования к памяти — напр. для моего примера в 20k пар потребуется минимум 4Гб памяти с учетом расходов на базовый софт. Пример конечно крайне простой и абстрактный, но думаю суть понятна. >Вообще, применительно к объему памяти "базовый порог входа" что призван означать?
Минимальный объем памяти для эффективного функционирования системы. Вы это хотели услышать ?
Здравствуйте, Anton Batenev, Вы писали:
AB>Слушай, ну это уже придирки к словам. Tiny она или small — это исключительно зависит от наблюдателя, работающего с конкретной коллекцией, имеющегося оборудования и здравого смысла.
Нет, это не придирки к словам. Это та граница, после которой по словам разработчиков имеет смысл горизонтально масштабироваться. Значит это именно та граница, которую в монго считают серьезной.
AB>Зависит от конфигурации сервера(ов) и требуемой скорострельности. Поскольку mongo легко масштабируется, можно стартовать на достаточно слабых серверах (в т.ч. VPS) и легко расширяться или мигрировать на более мощное оборудование вместе с ростом нагрузки и/или финансов.
РСУБД тоже позволяют легко мигрировать на более мощное оборудование. Единственное что, начальные требования у них побольше, чем у noSQL, но при росте они урв
Получается, что ниша монгодб — сверхмаленькие проекты, которые скорее всего не выстрелят? Чтобы целесообразно было запустить сотню мелких проектов на как можно более слабом железе с рассчетом на выстрел одного-двух, которые потом и масштабировать?
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, _ABC_, Вы писали: __>Я попытаюсь ответить так чтобы не впадать в троллинги не цитировать кэптана Очевидность
_AB>>Вопросы: _AB>>Что такое "отмасштабироваться по взрослому"? В цифрах и фактах, пожалуйста. __>Что такое масштабирование здесь. Я по крайней мере с тем что написано в wiki согласен. __>По взрослому — это когда вам следует нарастить возможности системы выше, чем "средние" возможности подобных систем. А какие уж характеристики/цифры у средних систем, решать вам самому (количество/"вес" данных в Гб, transactions per sec, users ?). Напр. есть замечательный блогосайт highscalability там хорошо все изложено (а писать долго и лениво )
Ну и почему у Вас тогда получается, что один сервер за 70 тысяч справляется хуже, чем три по пять?
_AB>>И чем определяется этот "базовый порог входа"? __>Постановкой задачи или задачей в развитии. Напр. в применении к арбитражу вам ставят следующую задачу: __>1) есть две разнесенные системы (два сайта, биржи, или игровые сервера — думаю не суть важно). __>2) в каждой из этих систем есть идентичный по сути объект, который обладает разными характеристиками (напр ценная бумага с разной стоимостью, или книжка/диск на сайте) __>3) Нужно получить данные объекта из двух систем, сравнить их и в зависимости от результата сравнения пары выполнить действие __>Вы смотрите физику и видите что каждый объект весит напр. 50kb. Значит чтобы сформировать пару нужно мин. 100k (в реальности больше, т.к. там будут доп. очереди, буферы и т.д.). Итого 10 пар = 1Мб, 10k пар 1 Гб, 100k пар — 10Гб. Издержки обработки должны быть минимальны (у нас же low latency в теории ). Таким образом вы можете прикинуть мин. требования к памяти — напр. для моего примера в 20k пар потребуется минимум 4Гб памяти с учетом расходов на базовый софт. Пример конечно крайне простой и абстрактный, но думаю суть понятна.
Суть понятна. Почему DL385 G7 с 2-мя процами и 32 ГБ оперативной пямяти за примерно 10 тысяч в данном случае справится хуже, чем 3 сервера с одним процом и 4 ГБ оперативы по пять тысяч каждый?
Здравствуйте, _ABC_, Вы писали:
_AB>Нет, это не придирки к словам. Это та граница, после которой по словам разработчиков имеет смысл горизонтально масштабироваться. Значит это именно та граница, которую в монго считают серьезной.
Зачем передёргивать то? ) Там вполне чётко сказано, что это минимальный порог, опускаясь ниже которого, скорее всего ничего хорошего не получишь. А вы интерпретировали это как "серьёзную границу, с которой стоит начинать" — типичное враньё. Думаю у них там где-нибудь на сайте можно поискать рекомендации на счёт того, с какого размера лучше начинать и думаю это будут совсем другие цифры.
Здравствуйте, _ABC_, Вы писали:
ABC> Нет, это не придирки к словам. Это та граница, после которой по словам разработчиков имеет смысл горизонтально масштабироваться. Значит это именно та граница, которую в монго считают серьезной.
Не соглашусь. Давай возьмем исходную фразу: "If the collection is small (less than say, 400MB) we recommend not bothering to shard it.". Если понимать буквально, то они не рекомендуют шардить коллекции менее, скажем, 400 метров, однако обратного совершенно не следует. При этом 400 метров, судя по "less than say" — условность, которая связана с тем, что linux (как основная платформа для mongo) может полноценно работать на достаточно широком диапазоне железа.
Т.о., tiny, small, medium, large — это все условности.
ABC> РСУБД тоже позволяют легко мигрировать на более мощное оборудование.
Там помимо миграции еще было масштабирование. Мигировать я могу любую базу простым копированием файловой системы в худшем случае. Но дело даже не в этом — у них тупо разные области решаемых задач.
ABC> Получается, что ниша монгодб — сверхмаленькие проекты, которые скорее всего не выстрелят? Чтобы целесообразно было запустить сотню мелких проектов на как можно более слабом железе с рассчетом на выстрел одного-двух, которые потом и масштабировать?
Странный вывод из моих слов. То, что mongo хорошо живет на слабом железе совершенно не означает, что это ее ниша. С ростом проекта любое железо рано или поздно становится слабым — сегодня у тебя 1К пользователей, завтра 100К, через год лям и выше — у меня просто не болит голова на тему роста mongo (но занята ростом нагрузки на postgres).
?
