Здравствуйте, alex_public, Вы писали:
_>1. А кто это сказал, что мы тут под работой понимаем OLTP? )
Я сказал. _>2. Я же вроде как ясно описал процесс моделирования — там совсем не read-only операции.
Вполне себе read-only. В моделировании изменения производятся не inplace, а рассчитывается следующий слой по предыдущим. Классика ФП. Конфликтов быть не может, понятия "несогласованности" нету, изоляция не нужна, атомарность не нужна, структура данных — примитивная.
Конечно тут RDBMS — оверкилл. Это как выполнять сложение двух байтов при помощи EC2.
_>Не факт. Для форумов возможно есть смысл посмотреть на СУБД оптимизированные под графы. А для ERP очень удобной (в первую очередь благодаря работе с json документами) может быть MongoDB
MongoDB к реальной жизни за пределами RAM не приспособлена. Почитайте http://schmichael.com/files/schmongodb/Scaling%20with%20MongoDB%20(with%20notes).pdf.
Особенно вдумчиво рекомендую посмотреть на слайды №10, №23, №27.
_>Какой ещё теории? ) Скажем для доступа к массиву данных тебе нужна специальная теория? )
Очень простой. Теории про то, как обеспечить сериализуемость операций в вашем языке запросов. Про это у Бернстайна есть целая книга.
Если у вас есть какие-то свежие мысли про то, как обеспечить ACID для "доступа к массиву данных" — велком, поделитесь.
_>А я и не говорил, что это сложно. Но главное же достигнутый результат.
Точнее, его отсутствие — ACID в Кассандре нету. Следующий, пжалста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>1. А кто это сказал, что мы тут под работой понимаем OLTP? ) S>Я сказал.
Ну так не надо пытаться ограничить всех участников дискуссии рамками своего маленького мирка. )
S>Конечно тут RDBMS — оверкилл. Это как выполнять сложение двух байтов при помощи EC2.
Правильно. Только надо ещё уточнить, что означает "оверкилл" в данном случае. А тут оно означает, что не просто можно работать без RDBMS, но и так будет намного быстрее варианта с RDBMS. Т.е. грубо говоря RDBMS тут является не просто не нужной, а даже мешающей! Ну а в случае алгоритмов с графами вообще не применимой.
S>MongoDB к реальной жизни за пределами RAM не приспособлена. Почитайте http://schmichael.com/files/schmongodb/Scaling%20with%20MongoDB%20(with%20notes).pdf. S>Особенно вдумчиво рекомендую посмотреть на слайды №10, №23, №27.
Ну да, у неё такая архитектура, как раз чтобы обеспечивать максимальную скорости. А обеспечить влезание в RAM на ней тривиально (благодаря автоматическому шардингу из коробки) — просто добавляем ещё один компьютер (причём обычный, простенький, а не покупаем дорогущий кластер, как в случае реляционных СУБД).
_>>Какой ещё теории? ) Скажем для доступа к массиву данных тебе нужна специальная теория? ) S>Очень простой. Теории про то, как обеспечить сериализуемость операций в вашем языке запросов. Про это у Бернстайна есть целая книга. S>Если у вас есть какие-то свежие мысли про то, как обеспечить ACID для "доступа к массиву данных" — велком, поделитесь.
Так "сереализуемость операций" — это у нас теперь такой синоним ACID? )
_>>А я и не говорил, что это сложно. Но главное же достигнутый результат. S>Точнее, его отсутствие — ACID в Кассандре нету. Следующий, пжалста.
Как забавно. Вроде как ACID в Кассандре нет, но при этом она обеспечивает надёжность большую, чем базы данных с вроде как наличием ACID. Из этого сразу возникает множество мыслей на тему самого ACID... )))
Здравствуйте, alex_public, Вы писали:
S>>Точнее, его отсутствие — ACID в Кассандре нету. Следующий, пжалста.
_>Как забавно. Вроде как ACID в Кассандре нет, но при этом она обеспечивает надёжность большую, чем базы данных с вроде как наличием ACID. Из этого сразу возникает множество мыслей на тему самого ACID... )))
Вот сделал ты две записи одну за другой, а сразу после этого некий клиент делает запрос и может увидеть, что вторая запись уже в базе, а первой еще нет. Для хранение твитов такое поведение еще допустимо, а для приложения, в котором есть какая-нибудь логика принятия решения на основании того, что лежит в базе, уже нет.
Здравствуйте, alex_public, Вы писали:
S>>MongoDB к реальной жизни за пределами RAM не приспособлена. Почитайте http://schmichael.com/files/schmongodb/Scaling%20with%20MongoDB%20(with%20notes).pdf. S>>Особенно вдумчиво рекомендую посмотреть на слайды №10, №23, №27.
_>Ну да, у неё такая архитектура, как раз чтобы обеспечивать максимальную скорости. А обеспечить влезание в RAM на ней тривиально (благодаря автоматическому шардингу из коробки)
Про автоматический шардинг там тоже написано. Кратко: он не работает.
_>Так "сереализуемость операций" — это у нас теперь такой синоним ACID? )
Сериализуемость — это синоним Isolation. Это буква I в слове ACID. Теории для атомарности и консистентности в общем случае более-менее есть.
_>Как забавно. Вроде как ACID в Кассандре нет, но при этом она обеспечивает надёжность большую, чем базы данных с вроде как наличием ACID. Из этого сразу возникает множество мыслей на тему самого ACID... )))
Надёжность, которую обеспечивает Кассандра — это Durability, последняя из четырёх букв. Насчёт "большей" надёжности — это пфф, маркетинг. К примеру, SQL Server Azure немножко подпилен, чтобы коммит проводить не на одной машине, а на двух из трёх. Т.е. durability в стиле Кассандры можно прикручивать поверх RDBMS, не жертвуя остальными буквами из ACID.
А без A, С, и I durability не особо то нужна. Зачем мне неконсистентные результаты частичного применения транзакций, которые перемешаны так, что не упорядлочить? Да ещё и "навечно", благодаря durability.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, artelk, Вы писали:
A>Вот сделал ты две записи одну за другой, а сразу после этого некий клиент делает запрос и может увидеть, что вторая запись уже в базе, а первой еще нет. Для хранение твитов такое поведение еще допустимо, а для приложения, в котором есть какая-нибудь логика принятия решения на основании того, что лежит в базе, уже нет.
Что значит одну за другой? Это в рамках одной транзакции или нет? )
Здравствуйте, Sinclair, Вы писали:
S>Про автоматический шардинг там тоже написано. Кратко: он не работает.
Угу, в презентации 2011-го года. ) Напомню, что сейчас 2015-ый, а сама СУБД родилась в 2009-ом. Т.е. с тех пор прошло вдвое больше времени, чем всё время жизни этой СУБД на тот момент. ))) Кстати, в твою любимую Azure MongoDB включили в 2012-ом. )
S>Надёжность, которую обеспечивает Кассандра — это Durability, последняя из четырёх букв. Насчёт "большей" надёжности — это пфф, маркетинг. К примеру, SQL Server Azure немножко подпилен, чтобы коммит проводить не на одной машине, а на двух из трёх. Т.е. durability в стиле Кассандры можно прикручивать поверх RDBMS, не жертвуя остальными буквами из ACID. S>А без A, С, и I durability не особо то нужна. Зачем мне неконсистентные результаты частичного применения транзакций, которые перемешаны так, что не упорядлочить? Да ещё и "навечно", благодаря durability.
Фокус в том, что получить нужную в конкретном случае разновидность ACID поверх nosql базы не сложно. См. например вот http://www.slideshare.net/m0nstermind/c-one-joker (кстати, обрати внимание на то, от чего они отказываются в пользу Кассандры). А вот получить автоматическое масштабирование современных sql баз на сеть компьютеров у тебя не выйдет.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, artelk, Вы писали:
A>>Вот сделал ты две записи одну за другой, а сразу после этого некий клиент делает запрос и может увидеть, что вторая запись уже в базе, а первой еще нет. Для хранение твитов такое поведение еще допустимо, а для приложения, в котором есть какая-нибудь логика принятия решения на основании того, что лежит в базе, уже нет.
_>Что значит одну за другой? Это в рамках одной транзакции или нет? )
Здравствуйте, alex_public, Вы писали:
_>Угу, в презентации 2011-го года. ) Напомню, что сейчас 2015-ый, а сама СУБД родилась в 2009-ом.
У вас есть более новая презентация? У меня — есть: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
_>Фокус в том, что получить нужную в конкретном случае разновидность ACID поверх nosql базы не сложно. См. например вот http://www.slideshare.net/m0nstermind/c-one-joker (кстати, обрати внимание на то, от чего они отказываются в пользу Кассандры). А вот получить автоматическое масштабирование современных sql баз на сеть компьютеров у тебя не выйдет.
Несложно??? my ass. Вы, наверное, шутите.
Во-первых, на 100 миллионов инсталляций RDBMS, в которых ACID из коробки, есть 1 инсталляция пропатченной кассандры.
Типичный сценарий применения NoSQL — это "я не понимаю, как работает SQL, поэтому дайте мне что-то, что умеет читать и писать JSON". В этом сценарии советовать "пойти пропатчить кассандру для получения true ACID" как-то странно.
Во-вторых, не факт, что этот подход применим для общего случая.
У одноклассников была, грубо говоря, одна транзакция. Не факт, что им не придётся ещё раз всё перепатчивать через годик, когда им потребуется оптимизировать другую операцию.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, artelk, Вы писали:
_>>Что значит одну за другой? Это в рамках одной транзакции или нет? ) A>А разница? Изоляции-то нет.
Вообще то если без транзакций, то указанная проблема будет и в реляционных БД.
Если же брать вариант с транзакций, то они имеются и у nosql БД, правда обычно несколько специфические (разные в каждой СУБД). Так что тут уже надо конкретно смотреть что за nosql СУБД используется и что подразумевается под записью. Весьма вероятно, что всё отлично совпадёт (а если нет, то значит неверно выбрана СУБД).
И где здесь сказано о неработоспособности автоматического шардинга? )
_>>Фокус в том, что получить нужную в конкретном случае разновидность ACID поверх nosql базы не сложно. См. например вот http://www.slideshare.net/m0nstermind/c-one-joker (кстати, обрати внимание на то, от чего они отказываются в пользу Кассандры). А вот получить автоматическое масштабирование современных sql баз на сеть компьютеров у тебя не выйдет. S>Несложно??? my ass. Вы, наверное, шутите.
Да даже если бы было сложно, но всё равно же это возможно. В отличие от варианта с классическими СУБД, где невозможно в принципе.
S>Во-первых, на 100 миллионов инсталляций RDBMS, в которых ACID из коробки, есть 1 инсталляция пропатченной кассандры. S>Типичный сценарий применения NoSQL — это "я не понимаю, как работает SQL, поэтому дайте мне что-то, что умеет читать и писать JSON". В этом сценарии советовать "пойти пропатчить кассандру для получения true ACID" как-то странно.
Ну так вообще то и полноценный ACID мягко говоря не всегда нужен. Особенно это касается веб приложений. И кстати говоря они в начале использовали Кассандру без всяких правок (для других целей). Это потом они решили расширить её применение ещё и на область ранее занятую SQL Server, где и понадобилась классическая реализация ACID.
S>Во-вторых, не факт, что этот подход применим для общего случая.
А никто и не говорит про общий случай. Но в каждом конкретном случае это вполне реально. Кстати, очень напоминает ситуацию с нашей же изначальной дискуссий тут, насчёт ORM, слоя абстракции БД и т.п. Там опять же возможна медленная универсальная реализация и быстрая, но написанная под конкретную задачу.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, artelk, Вы писали:
_>>>Что значит одну за другой? Это в рамках одной транзакции или нет? ) A>>А разница? Изоляции-то нет.
_>Вообще то если без транзакций, то указанная проблема будет и в реляционных БД.
Пруф?
AFAIK, "без транзакций" в РСУБД означает "транзакция на каждый statement с автокоммитом".
_>Если же брать вариант с транзакций, то они имеются и у nosql БД, правда обычно несколько специфические (разные в каждой СУБД). Так что тут уже надо конкретно смотреть что за nosql СУБД используется и что подразумевается под записью.
А что, с точки зрения добавляющего запись клиента, может подразумеваться под законченой записью, помимо того, что база ответила "ok, written" после операции записи? Или нужно вручную пройтись по всем узлам, откуда запись может быть потенциально запрошена другим клиентом и ждать, пока запись не приедет на каждую из них? Спасибо, не надо.
_>Весьма вероятно, что всё отлично совпадёт (а если нет, то значит неверно выбрана СУБД).
Значит вместо базы данных выбрана хранилка для твитов.
Здравствуйте, artelk, Вы писали:
_>>Вообще то если без транзакций, то указанная проблема будет и в реляционных БД. A>Пруф? A>AFAIK, "без транзакций" в РСУБД означает "транзакция на каждый statement с автокоммитом".
Ну ок, не важно что оно там. Имеем два запроса к БД, в каждом добавляется новая запись. Какие гарантии, что параллельный клиент не сможет сделать запрос, который вернёт только одну запись? )
_>>Если же брать вариант с транзакций, то они имеются и у nosql БД, правда обычно несколько специфические (разные в каждой СУБД). Так что тут уже надо конкретно смотреть что за nosql СУБД используется и что подразумевается под записью. A>А что, с точки зрения добавляющего запись клиента, может подразумеваться под законченой записью, помимо того, что база ответила "ok, written" после операции записи? Или нужно вручную пройтись по всем узлам, откуда запись может быть потенциально запрошена другим клиентом и ждать, пока запись не приедет на каждую из них? Спасибо, не надо.
Эмм, тут речь совсем о другом была. Про то, что конкретно представляет собой запись, в смысле формата данных. Это в реляционных СУБД всё просто — строка в таблице. А в случае nosql это же может быть что угодно. К примеру некий массив где-то в глубинах некого json документа. И соответственно правила на атомарность, транзакции и т.п. будут везде разными — надо смотреть конкретную СУБД и конкретную модель данных.
A>Значит вместо базы данных выбрана хранилка для твитов.
Ирония в том, что с огромным увеличением числа всех этих твиттеров и т.п., эти самых хранилки для твитом могут стать мейнстримом в индустрии. ))) Потому как в нашем мире востребованность решения гораздо важнее красоты технологии.
Здравствуйте, alex_public, Вы писали:
_>Ну ок, не важно что оно там. Имеем два запроса к БД, в каждом добавляется новая запись. Какие гарантии, что параллельный клиент не сможет сделать запрос, который вернёт только одну запись? )
Это не имеет смысла обсуждать — в РСУБД транзакции есть всегда. И клиент выбирает — делать ли обе вставки в рамках одной транзакции, либо в разных. В первом случае, благодаря изоляции, никакой сторонний наблюдатель не увидит нечётного количества записей в таблице.
Речь идёт о том, что если полноценных транзакций нету, как в большинстве NoSQL баз данных, то никакого выбора у клиента нет.
_>Эмм, тут речь совсем о другом была. Про то, что конкретно представляет собой запись, в смысле формата данных. Это в реляционных СУБД всё просто — строка в таблице. А в случае nosql это же может быть что угодно. К примеру некий массив где-то в глубинах некого json документа. И соответственно правила на атомарность, транзакции и т.п. будут везде разными — надо смотреть конкретную СУБД и конкретную модель данных.
Формат данных никакого отношения к ACID не имеет. Транзакции означают возможность применить блок произвольных изменений атомарно и изолированно. Как только начинаются разговоры про "ну, смотря какие там изменения" — это означает, что поддержки транзакций нет, и вам пытаются продать фуфло.
_>Ирония в том, что с огромным увеличением числа всех этих твиттеров и т.п., эти самых хранилки для твитом могут стать мейнстримом в индустрии. ))) Потому как в нашем мире востребованность решения гораздо важнее красоты технологии.
Нам к иронии не привыкать. К примеру, подавляющая популярность PHP и JS с точки зрения их совершенства как платформ — прямо таки comedy club.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Вкратце так: при записи монга не гарантирует что данные реально записались (и будут прочитаны следующими запросами) хотя бы на одну ноду. При попытке подрутить гарантии, чтобы клиент ждал реальной записи — все сильно тормозит, что сводит на нет преимущества в скорости.
_>>>Фокус в том, что получить нужную в конкретном случае разновидность ACID поверх nosql базы не сложно. См. например вот http://www.slideshare.net/m0nstermind/c-one-joker (кстати, обрати внимание на то, от чего они отказываются в пользу Кассандры). А вот получить автоматическое масштабирование современных sql баз на сеть компьютеров у тебя не выйдет. S>>Несложно??? my ass. Вы, наверное, шутите. _>Да даже если бы было сложно, но всё равно же это возможно. В отличие от варианта с классическими СУБД, где невозможно в принципе.
Что за глупости?
На том уровне как они реализовали тоже самое можно сделать с любой субд. База нарезается на непересекающиеся шарды по partition key, для каждого шарда ставится один и более инстаносов и пишется middleware, который выполняет несколько функций:
1) поддерживает мапинг id шарда -> инстансы
2) распределяет запись с заданным уровнем надежности (ОК после первого ответа, после половины ответов итп)
3) обеспечивает retry операций записи
4) делает простые джоины для разных шардов
Собственно так и было сделано в твиттере, фб и прочих соцсетях. А уже спустя много лет они изобрели свои движки, которые оптимизированы под их сценарии. А дальше маркетинг noSQL сделал свое дело. Все как-то внезапно стали думать, что если что-то умеет noSQL база, то того же самого нельзя добиться на РСУБД.
S>>Во-первых, на 100 миллионов инсталляций RDBMS, в которых ACID из коробки, есть 1 инсталляция пропатченной кассандры. S>>Типичный сценарий применения NoSQL — это "я не понимаю, как работает SQL, поэтому дайте мне что-то, что умеет читать и писать JSON". В этом сценарии советовать "пойти пропатчить кассандру для получения true ACID" как-то странно.
_>А никто и не говорит про общий случай. Но в каждом конкретном случае это вполне реально. Кстати, очень напоминает ситуацию с нашей же изначальной дискуссий тут, насчёт ORM, слоя абстракции БД и т.п. Там опять же возможна медленная универсальная реализация и быстрая, но написанная под конкретную задачу.
Проблема в том, что у тебя в одном приложении много таких "конкретных случаев" и велосипед под каждый из них скорее всего приведет к повышенному расходу ресурсов с примерно тем же уровнем быстродействия.
Здравствуйте, Sinclair, Вы писали:
S>Это не имеет смысла обсуждать — в РСУБД транзакции есть всегда. И клиент выбирает — делать ли обе вставки в рамках одной транзакции, либо в разных. В первом случае, благодаря изоляции, никакой сторонний наблюдатель не увидит нечётного количества записей в таблице. S>Речь идёт о том, что если полноценных транзакций нету, как в большинстве NoSQL баз данных, то никакого выбора у клиента нет.
Ну так мой собеседник утверждал, что в реляционных БД и без транзакций не будет никаких проблем. )))
S>Формат данных никакого отношения к ACID не имеет. Транзакции означают возможность применить блок произвольных изменений атомарно и изолированно. Как только начинаются разговоры про "ну, смотря какие там изменения" — это означает, что поддержки транзакций нет, и вам пытаются продать фуфло.
Очень даже имеет. Это в реляционных БД понятие транзакции является строго определённым. А в мире nosql БД оно своё у каждой СУБД. Более того, у некоторых СУБД оно зависит от используемой модели данных и запросов. Т.е. в конкретной СУБД и для конкретной модели данных определённые запросы легко вкладываются в транзакцию, а другие нет.
S>Нам к иронии не привыкать. К примеру, подавляющая популярность PHP и JS с точки зрения их совершенства как платформ — прямо таки comedy club.
Здравствуйте, gandjustas, Вы писали:
_>>И где здесь сказано о неработоспособности автоматического шардинга? ) G>Это по другой ссылке http://schmichael.com/files/schmongodb/Scaling%20with%20MongoDB%20(with%20notes).pdf G>Вкратце так: при записи монга не гарантирует что данные реально записались (и будут прочитаны следующими запросами) хотя бы на одну ноду. При попытке подрутить гарантии, чтобы клиент ждал реальной записи — все сильно тормозит, что сводит на нет преимущества в скорости.
Хм, ты бы глянул на дискуссию хотя бы на один уровень выше. ))) Именно с обсуждения этой презентации (и её даты создания) и пошёл разговор. )))
_>>Да даже если бы было сложно, но всё равно же это возможно. В отличие от варианта с классическими СУБД, где невозможно в принципе. G>Что за глупости? G>На том уровне как они реализовали тоже самое можно сделать с любой субд. База нарезается на непересекающиеся шарды по partition key, для каждого шарда ставится один и более инстаносов и пишется middleware, который выполняет несколько функций: G>1) поддерживает мапинг id шарда -> инстансы G>2) распределяет запись с заданным уровнем надежности (ОК после первого ответа, после половины ответов итп) G>3) обеспечивает retry операций записи G>4) делает простые джоины для разных шардов
Ну так нарезается (если это вообще возможно) база же руками, правильно? ) Т.е. как ты не дописывай код, но автоматический шардинг ты не получишь.
G>Собственно так и было сделано в твиттере, фб и прочих соцсетях. А уже спустя много лет они изобрели свои движки, которые оптимизированы под их сценарии. А дальше маркетинг noSQL сделал свое дело. Все как-то внезапно стали думать, что если что-то умеет noSQL база, то того же самого нельзя добиться на РСУБД.
Угу, и сделали они эти движки как раз потому, что утомились затачивать руками РСУБД под подобные "неудобные" задачи.
G>Проблема в том, что у тебя в одном приложении много таких "конкретных случаев" и велосипед под каждый из них скорее всего приведет к повышенному расходу ресурсов с примерно тем же уровнем быстродействия.
С чего бы это? ) Максимум это может привести к раздутию размеров исполняемого файла (на что в общем то всем давно наплевать).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>И где здесь сказано о неработоспособности автоматического шардинга? ) G>>Это по другой ссылке http://schmichael.com/files/schmongodb/Scaling%20with%20MongoDB%20(with%20notes).pdf G>>Вкратце так: при записи монга не гарантирует что данные реально записались (и будут прочитаны следующими запросами) хотя бы на одну ноду. При попытке подрутить гарантии, чтобы клиент ждал реальной записи — все сильно тормозит, что сводит на нет преимущества в скорости.
_>Хм, ты бы глянул на дискуссию хотя бы на один уровень выше. ))) Именно с обсуждения этой презентации (и её даты создания) и пошёл разговор. )))
А ничего толком с тех пор не изменилось. Разве что safe=true по умолчанию теперь, но надежность кластера монги оставляет желать лучшего и по сей день.
_>>>Да даже если бы было сложно, но всё равно же это возможно. В отличие от варианта с классическими СУБД, где невозможно в принципе. G>>Что за глупости? G>>На том уровне как они реализовали тоже самое можно сделать с любой субд. База нарезается на непересекающиеся шарды по partition key, для каждого шарда ставится один и более инстаносов и пишется middleware, который выполняет несколько функций: G>>1) поддерживает мапинг id шарда -> инстансы G>>2) распределяет запись с заданным уровнем надежности (ОК после первого ответа, после половины ответов итп) G>>3) обеспечивает retry операций записи G>>4) делает простые джоины для разных шардов
_>Ну так нарезается (если это вообще возможно) база же руками, правильно? ) Т.е. как ты не дописывай код, но автоматический шардинг ты не получишь.
Что значит "руками" ? Такие же SQL запросы. Только middleware знает куда их отправлять надо.
G>>Собственно так и было сделано в твиттере, фб и прочих соцсетях. А уже спустя много лет они изобрели свои движки, которые оптимизированы под их сценарии. А дальше маркетинг noSQL сделал свое дело. Все как-то внезапно стали думать, что если что-то умеет noSQL база, то того же самого нельзя добиться на РСУБД. _>Угу, и сделали они эти движки как раз потому, что утомились затачивать руками РСУБД под подобные "неудобные" задачи.
Да тут не в удобстве дело, а в масштабе. Когда у тебя петабайты данных и 100500 тыщ одновременных запросов, то реальное чтение с диска и реальная запись на диск становится проблемой.
При этом если лайк или твит потеряется, то никто никогда этого даже не заметит. Поэтому им можно максимально расслабить требования надежности записи, а также согласованности (без разницы если половина пользователей твой лайк не увидят), но получить высокую скорость записи и чтения.
Многие по глупости думаю что у них такие же сценарии. Но это не так. Даже в вебе контент — критически важный элемент, для которого нужно обеспечить надежность и согласованность. А в бизнес-приложениях на пушечный выстрел нельзя пускать хранилища, которые могут не сохранить данные или получить неупорядоенный результат конкурентных транзакций.
G>>Проблема в том, что у тебя в одном приложении много таких "конкретных случаев" и велосипед под каждый из них скорее всего приведет к повышенному расходу ресурсов с примерно тем же уровнем быстродействия. _>С чего бы это? ) Максимум это может привести к раздутию размеров исполняемого файла (на что в общем то всем давно наплевать).
С того, что бесплатного сыра не бывает.
Если ты теряешь гарантии на стороне хранилища, то вынужден писать код, который узнает результат, это дополнительный раунд-трип на сервер как минммум.
Если ты отказываешься от linq в пользу ручной склейки строк или более слабого генератора, который работает быстрее, то ты вряд ли сможешь сделать хорошие проекции под каждый сценарий, поэтому твои запросы в среднем будут работать дольше, чем с linq.
Просто если ты не занимался разработкой больших систем с конкурентным доступом, то ты можешь и не подозревать об этих проблемах.
Здравствуйте, gandjustas, Вы писали:
G>А ничего толком с тех пор не изменилось. Разве что safe=true по умолчанию теперь, но надежность кластера монги оставляет желать лучшего и по сей день.
Надёжность там опять же достигается установкой дополнительных серверов. )
_>>Ну так нарезается (если это вообще возможно) база же руками, правильно? ) Т.е. как ты не дописывай код, но автоматический шардинг ты не получишь. G>Что значит "руками" ? Такие же SQL запросы. Только middleware знает куда их отправлять надо.
Правильно, а откуда оно знает? ) Кто и где задаёт эти настройки? )
G>Да тут не в удобстве дело, а в масштабе. Когда у тебя петабайты данных и 100500 тыщ одновременных запросов, то реальное чтение с диска и реальная запись на диск становится проблемой. G>При этом если лайк или твит потеряется, то никто никогда этого даже не заметит. Поэтому им можно максимально расслабить требования надежности записи, а также согласованности (без разницы если половина пользователей твой лайк не увидят), но получить высокую скорость записи и чтения. G>Многие по глупости думаю что у них такие же сценарии. Но это не так. Даже в вебе контент — критически важный элемент, для которого нужно обеспечить надежность и согласованность. А в бизнес-приложениях на пушечный выстрел нельзя пускать хранилища, которые могут не сохранить данные или получить неупорядоенный результат конкурентных транзакций.
Согласен. Но с поправкой на пару нюансов:
1. Всё же nosql мир намного более неоднороден. Т.е. в реальности у нас не чёрно-белая картина типа "в sql БД гарантии есть, а в nosql нет", а гораздо более сложная: "в slq БД гарантии есть, а в nosql имеем полный спектр вариантов (от нуля и до уровня slq)." Всё зависит от выбора конкретной СУБД и конкретной модели данных.
2. С учётом тенденций развития веб'а (где в очень многих случаях сильные гарантии не нужны) именно nosql решения могут стать лидирующими.
_>>С чего бы это? ) Максимум это может привести к раздутию размеров исполняемого файла (на что в общем то всем давно наплевать). G>С того, что бесплатного сыра не бывает.
Во-первых не бесплатно, а ценой работы программистов. Соответственно во многих случаях действительно выгоднее просто купить более мощный сервер. Но это далеко не всегда. К примеру в случае какого-нибудь Яндекса (где пара процентов производительности будет означать тысячи серверов) или наоборот встроенных приложений (где мы упираемся в производительность железа, которое не размножишь) и т.д. и т.п.
G>Если ты теряешь гарантии на стороне хранилища, то вынужден писать код, который узнает результат, это дополнительный раунд-трип на сервер как минммум.
Это если все гарантии необходимы. А в конкретном частом случае например могут быть нужные только какие-то простейшие гарантии.
G>Если ты отказываешься от linq в пользу ручной склейки строк или более слабого генератора, который работает быстрее, то ты вряд ли сможешь сделать хорошие проекции под каждый сценарий, поэтому твои запросы в среднем будут работать дольше, чем с linq.
Ну так зато в таком случае проблема переходит из технической области в административную ( грубо говоря как руководителю разработчиков заставить написать их все нужные оптимальные запросы).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>А ничего толком с тех пор не изменилось. Разве что safe=true по умолчанию теперь, но надежность кластера монги оставляет желать лучшего и по сей день.
_>Надёжность там опять же достигается установкой дополнительных серверов. )
Ты наверное не понимаешь, что означает Durability. Это означает что записанные данные будут прочитаны, даже в случае сбоя в следующий момент после записи.
Кластер монги не обеспечивает такого, так как локальный ОК от монги не гарантирует записи на диск, а ждать ОК от всех серверов — слишком дорогое занятие.
Но даже если нода упала, то синхронизация кластера может не закончится в обозримое время. В итоге при отказах очень велика вероятность вообще никуда не записать данные.
Читай внимательно презентацию по ссылке.
Это я уже не говорю об упорядоченности операций.
_>>>Ну так нарезается (если это вообще возможно) база же руками, правильно? ) Т.е. как ты не дописывай код, но автоматический шардинг ты не получишь. G>>Что значит "руками" ? Такие же SQL запросы. Только middleware знает куда их отправлять надо. _>Правильно, а откуда оно знает? ) Кто и где задаёт эти настройки? )
Админ при установке инстанса. Также как в nosql базах. Или ты думаешь, что это большая проблема?
G>>Да тут не в удобстве дело, а в масштабе. Когда у тебя петабайты данных и 100500 тыщ одновременных запросов, то реальное чтение с диска и реальная запись на диск становится проблемой. G>>При этом если лайк или твит потеряется, то никто никогда этого даже не заметит. Поэтому им можно максимально расслабить требования надежности записи, а также согласованности (без разницы если половина пользователей твой лайк не увидят), но получить высокую скорость записи и чтения. G>>Многие по глупости думаю что у них такие же сценарии. Но это не так. Даже в вебе контент — критически важный элемент, для которого нужно обеспечить надежность и согласованность. А в бизнес-приложениях на пушечный выстрел нельзя пускать хранилища, которые могут не сохранить данные или получить неупорядоченный результат конкурентных транзакций.
_>Согласен. Но с поправкой на пару нюансов: _>1. Всё же nosql мир намного более неоднороден. Т.е. в реальности у нас не чёрно-белая картина типа "в sql БД гарантии есть, а в nosql нет", а гораздо более сложная: "в slq БД гарантии есть, а в nosql имеем полный спектр вариантов (от нуля и до уровня slq)." Всё зависит от выбора конкретной СУБД и конкретной модели данных.
Это тоже маркетинговый миф. Подавляющее большинство noSQL решений не умеет делать честные ACID транзакции и никакими настройками это не исправишь. А без них сохранять консистентность при сложносвязной структуре данных невозможно.
_>2. С учётом тенденций развития веб'а (где в очень многих случаях сильные гарантии не нужны) именно nosql решения могут стать лидирующими.
Это очень сильное заявление. noSQL в вебе подходит только для readonly сценариев с выборкой по ключу, то есть статических сайтов. Но умные люди уже научились генерировать статические сайты на голом HTML и неважно что работает в бекэнде. Как только появляется динамика и сложные запросы — noSQL сосет.
_>>>С чего бы это? ) Максимум это может привести к раздутию размеров исполняемого файла (на что в общем то всем давно наплевать). G>>С того, что бесплатного сыра не бывает.
_>Во-первых не бесплатно, а ценой работы программистов. Соответственно во многих случаях действительно выгоднее просто купить более мощный сервер. Но это далеко не всегда. К примеру в случае какого-нибудь Яндекса (где пара процентов производительности будет означать тысячи серверов) или наоборот встроенных приложений (где мы упираемся в производительность железа, которое не размножишь) и т.д. и т.п.
Ты неправильно понял. Потеря гарантий всегда влечет за собой больше операций для того, чтобы эти гарантии частично восстановить. И очень часто бывает, что дополнительные операции отнимают в итоге больше времени, чем сэкономили. Причем со временем количество дополнительных операций растет и накладные расходы тоже растут. Про труд программистов я даже не говорю.
G>>Если ты теряешь гарантии на стороне хранилища, то вынужден писать код, который узнает результат, это дополнительный раунд-трип на сервер как минммум. _>Это если все гарантии необходимы. А в конкретном частом случае например могут быть нужные только какие-то простейшие гарантии.
В OLTP они всегда необходимы. Будь то форум или банковский процессинг. Отсутствие такой необходимости это или мусор (твиты, лайки), или статический сайт (то есть readonly по ключу).
G>>Если ты отказываешься от linq в пользу ручной склейки строк или более слабого генератора, который работает быстрее, то ты вряд ли сможешь сделать хорошие проекции под каждый сценарий, поэтому твои запросы в среднем будут работать дольше, чем с linq. _>Ну так зато в таком случае проблема переходит из технической области в административную ( грубо говоря как руководителю разработчиков заставить написать их все нужные оптимальные запросы).
В корне каждой административной проблемы лежит техническая. Заставить возможно, но это тупо затраты увеличит настолько, что проект станет нерентабельным.
Здравствуйте, gandjustas, Вы писали:
_>>Правильно, а откуда оно знает? ) Кто и где задаёт эти настройки? ) G>Админ при установке инстанса. Также как в nosql базах. Или ты думаешь, что это большая проблема?
Порезать БД на части? ) Да, это большая проблема. Собственно она даже не всегда гарантированно решаема. И в nosql базах с автоматическом шардингом этим заниматься не надо. Там настраиваются только связи между серверами.
_>>Согласен. Но с поправкой на пару нюансов: _>>1. Всё же nosql мир намного более неоднороден. Т.е. в реальности у нас не чёрно-белая картина типа "в sql БД гарантии есть, а в nosql нет", а гораздо более сложная: "в slq БД гарантии есть, а в nosql имеем полный спектр вариантов (от нуля и до уровня slq)." Всё зависит от выбора конкретной СУБД и конкретной модели данных. G>Это тоже маркетинговый миф. Подавляющее большинство noSQL решений не умеет делать честные ACID транзакции и никакими настройками это не исправишь. А без них сохранять консистентность при сложносвязной структуре данных невозможно.
Ну так ты сам же подтверждаешь мои слова. Да, соответствующих верхней границе спектра (полный аналоги транзакций из РСУБД) не много (но есть!). Но в остальных то тоже обычно что-то есть. Всяческие разновидности "лёгких" транзакций, которые формально не подходят под ACID. Так вот "лёгкие" это не означает, что они работают как-то наполовину или неправильно. Там абсолютно точно такое же поведение как и у РСУБД. Просто применимы они не ко всем операциям/данным, потому и лёгкие. Ну так а если в нашей задаче будут нужны только как раз подходящие запросы (или если говорить более корректно: если мы правильно выбрали СУБД под нашу задачу), то какие проблемы? )
_>>2. С учётом тенденций развития веб'а (где в очень многих случаях сильные гарантии не нужны) именно nosql решения могут стать лидирующими. G>Это очень сильное заявление. noSQL в вебе подходит только для readonly сценариев с выборкой по ключу, то есть статических сайтов. Но умные люди уже научились генерировать статические сайты на голом HTML и неважно что работает в бекэнде. Как только появляется динамика и сложные запросы — noSQL сосет.
Ты же сам приводил примеры с лайками и т.п.))) В которых сосёт как раз sql решение, за счёт трат ресурсов на поддержание ненужных гарантий и плохого масштабирования. Ну а вообще будущее похоже за так называемыми NewSql решениями, где можно будет получить и масштабирование и нужные гибкие гарантии. Вот только весь вопрос в том, на чём будут основаны эти решения. К примеру если глянуть сюда http://www.slideshare.net/m0nstermind/c-one-joker, то видно что в основу они положили nosql решение. Хотя у них была уже полностью развёрнутая инфраструктура на базе SQL Server (от которой как раз и отказываются в пользу NewSql решения).
G>Ты неправильно понял. Потеря гарантий всегда влечет за собой больше операций для того, чтобы эти гарантии частично восстановить. И очень часто бывает, что дополнительные операции отнимают в итоге больше времени, чем сэкономили. Причем со временем количество дополнительных операций растет и накладные расходы тоже растут. Про труд программистов я даже не говорю.
Ну так это означает что подобный переход был глупым и его инициатора надо выгонять. ) Только вот это скорее исключение из правил. Всё же обычно нормальные специалисты в начале всё измерят, а только потом переходят. И в большинстве случаев получают ускорение.
_>>Это если все гарантии необходимы. А в конкретном частом случае например могут быть нужные только какие-то простейшие гарантии. G>В OLTP они всегда необходимы. Будь то форум или банковский процессинг. Отсутствие такой необходимости это или мусор (твиты, лайки), или статический сайт (то есть readonly по ключу).
А где оно на форуме необходимо то? )))
_>>Ну так зато в таком случае проблема переходит из технической области в административную ( грубо говоря как руководителю разработчиков заставить написать их все нужные оптимальные запросы). G>В корне каждой административной проблемы лежит техническая. Заставить возможно, но это тупо затраты увеличит настолько, что проект станет нерентабельным.
Ну так зависит от ситуации. Я же уже описал варианты. Понятно, что если альтернативой служит покупка одного нового сервера, то лучше его купить. А если альтернативой служит покупка тысяч серверов, или повышение на 10% себестоимости устройства с тиражом в миллионы, то лучше уж напрячь программистов. )))
) и пошёл разговор. )))