Ну ей богу, что вы привязались к хистори? =)
Если уж приводить аналогию из фотошопа, то это скорее adjustment layers, а не хистори. Этот подход уже работает точно так, как описывает автор, в существующих приложениях — посмотрите, и сами все поймете.
Что «хистори»? Идея тут не в хистори, а в унификации подхода к обработке — все действия являются узлами дерева обработки изображения, что позволяет производить неразрушающее редактирование, в отличие от фотошопа, где часть действий меняет исходник, а часть — нет. Хистори тут — побочный продукт.
Не совсем понял «работает не с запросом, а только параметрами».
По поводу «back» не понял, можно поподробнее?
Если я правильно понял идею loadData:
0. пользователь переходит на некий адрес в нашем приложении с about:blank
1. пользователь вызывает некое действие, вызывающее смену маршрута
2. роутер вызывает loadData, которая возвращает deferred
3. роутер ждет разрешения deferred
4. роутер меняет адресную строку и вызывает onRoute.
Если я прав на счет №№3 и 4, то при нажатии back на шаге 3 произойдет переход на about:blank.
События (on, before, after, once) есть, есть и так называемые scopes (обработчики для сегмента пути, например, для /profile/common и /profile/contacts назначить один общий обработчик для profile, и отдельные для common и contacts), обработка «404», поддержка хеша и history api, никаких зависимостей, работа на сервере и клиенте, и прочее, и прочее.
Из отсутствующих вещей я на вскидку вижу только «переключение адреса до разрешения некоего deferred», но это, на самом деле, спорная фича: если ссылка поменяется сразу, то выполняемое действие можно, например, отменить нажатием кнопки «назад», а так этой возможности нет.
Ну, положа руку на сердце, ставят пиратки не просто из за желания «ultimate super douper deluxe edition», а из за того, что реально нужны некоторые возможности — совместимость форматов, как в случае с офисом, или одна-две реально нужные фичи и привычный UI — как в случае с фотошопом. За отсутствие геморроя с совместимостью или одну-две фичи платить более нескольких десятков долларов не очень хочется, особенно, когда есть возможность спиратить. Вон, JetBrains выпустили бесплатную IDEA, которая содержит все необходимые фичи для индивидуальной работы, и набор маленьких IDE, заточенных под конкретные платформы, и правильно лимитированных в функциональности, при этом стоящих вменяемые деньги для физ. лиц, плюс, они еще проводят периодические распродажи, и делают дешевый апгрейд версий — и все довольны, все хорошо, пиратская версия IDEA никому не нужна, а пользователи убеждают корпорации покупать их продукт (уже за сильно другие деньги). Те, кому нужен фотошоп, и кто не готов платить 700 долларов — будут его пиратить несмотря ни на что, это надо понять и принять, как данность.
А терабайт пытались с ленты восстановить, например? Это достаточно долго, в отдельных случаях подобная задержка недопустима (я недавно с таким сталкивался — как раз терабайт был, восстановление из бэкапа несколько часов шло). Так что уже в любом случае не один сервер нужен, а минимум два. Опять же, в случае смерти одного из зеркалируемых серверов получаем задержку (если это был мастер) на подъем слейва до мастера, потом значительное падение производительности (остался-то один сервер), а потом еще тратим время на синхронизацию, причем до полной синхронизации есть вероятность вообще все потерять, т.к. живой сервер только один. Так что добавляем еще третий сервер, падение производительности меньше, но все равно есть задержка на переключение мастера, например.
И вот тут становятся понятны преимущества 16 маленьких дешевых шардированных серверов по сравнению с тремя большими и дорогими с репликацией — при шардинге подобный инцидент никто не заметил бы, кроме техников.
Есть, конечно варианты — можно использовать, например, сетевое хранилище, общее для двух серверов, но это уже совсем другие деньги начинаются, а преимуществ (для типичных веб-задач) у шестнадцати серверов все равно больше.
Удаление автора комментария вообще-то обычно не должно приводить к удалению комментария.
Но вообще да — в подобных системах подразумевается, что согласованностью данных будет заниматься приложение.
Эффективность работы с диском вполне может быть сравнимой с RDBMS — можно, например, максимально хранить данные в памяти, а на диск писать changelog. Учитывая то, что обычно у подобных систем нет проблем с шардингом, можно обеспечить вариант, когда диск используется только на случай отключения питания, а работа ведется с данными в памяти.
В общем, мысль такова: нет ни одной задачи по выборке данных, которую можно было бы решить на MySQL, и нельзя было бы решить с помощью NoSQL. Возможно, придется самому поработать интерпретатором и оптимизатором запросов, но тем не менее, ничего невозможного. Разница между ними в другом — тут уже много говорили про это.
Ну, если внимательно прочитать комментарий, то станет понятно, что в нем не утверждается, что NoSQL-решения абсолютно неприменимы в банковском секторе. Комментарий вообще про другое.
А никто про согласованность не говорит, на ряде задач этим можно пожертвовать в угоду доступности и легкости масштабирования. Понятно, что где-нибудь в банковском секторе это, возможно, не будет работать, но есть много других проектов, с другими требованиями (особенно учитывая стоимость решения по сравнению с аналогичным на традиционной RDBMS).
Может быть несколько тысяч серверов, например, у каждого будет по куску данных, помещающемуся в оперативку — сколько там сейчас можно в недорогой сервер воткнуть памяти, 96Гб, 128Гб, больше?
Ну я про то, что не SQL избыточен, его просто не получается использовать на таких задачах. Если бы был удобный способ использовать SQL в таких условиях — я был бы только за, но пока я не видел таких решений.
А зачем?
В смысле, при таком подходе от mysql ничего не останется, то есть не будет разницы между ним и, скажем, mongodb в плане функционала. Плюс, придется самому дополнительно пилить логику шардинга, которая уже реализована в mongo из коробки.
Нет, не так. В вебе отдельные запросы редко когда бывают очень уж сложными и требующими большой производительности, но зато их очень много. И тогда экономически более выгодно становится делать много маленьких и дешевых серверов вместо одного мощного и дорогого. Это требует соответствующих подходов в разработке.
RDBMS на такую ситуацию не рассчитаны, а NoSQL-системы (которые здесь в основном обсуждают) как раз для этого и создавались. В этом весь смысл NoSQL, а вовсе не в избыточности RDBMS.
Если уж приводить аналогию из фотошопа, то это скорее adjustment layers, а не хистори. Этот подход уже работает точно так, как описывает автор, в существующих приложениях — посмотрите, и сами все поймете.
Если я правильно понял идею loadData:
0. пользователь переходит на некий адрес в нашем приложении с about:blank
1. пользователь вызывает некое действие, вызывающее смену маршрута
2. роутер вызывает loadData, которая возвращает deferred
3. роутер ждет разрешения deferred
4. роутер меняет адресную строку и вызывает onRoute.
Если я прав на счет №№3 и 4, то при нажатии back на шаге 3 произойдет переход на about:blank.
было в Симпсонахреализовано: www.thefoundry.co.uk/products/nuke/События (on, before, after, once) есть, есть и так называемые scopes (обработчики для сегмента пути, например, для /profile/common и /profile/contacts назначить один общий обработчик для profile, и отдельные для common и contacts), обработка «404», поддержка хеша и history api, никаких зависимостей, работа на сервере и клиенте, и прочее, и прочее.
Из отсутствующих вещей я на вскидку вижу только «переключение адреса до разрешения некоего deferred», но это, на самом деле, спорная фича: если ссылка поменяется сразу, то выполняемое действие можно, например, отменить нажатием кнопки «назад», а так этой возможности нет.
И вот тут становятся понятны преимущества 16 маленьких дешевых шардированных серверов по сравнению с тремя большими и дорогими с репликацией — при шардинге подобный инцидент никто не заметил бы, кроме техников.
Есть, конечно варианты — можно использовать, например, сетевое хранилище, общее для двух серверов, но это уже совсем другие деньги начинаются, а преимуществ (для типичных веб-задач) у шестнадцати серверов все равно больше.
Но вообще да — в подобных системах подразумевается, что согласованностью данных будет заниматься приложение.
Эффективность работы с диском вполне может быть сравнимой с RDBMS — можно, например, максимально хранить данные в памяти, а на диск писать changelog. Учитывая то, что обычно у подобных систем нет проблем с шардингом, можно обеспечить вариант, когда диск используется только на случай отключения питания, а работа ведется с данными в памяти.
В смысле, при таком подходе от mysql ничего не останется, то есть не будет разницы между ним и, скажем, mongodb в плане функционала. Плюс, придется самому дополнительно пилить логику шардинга, которая уже реализована в mongo из коробки.
RDBMS на такую ситуацию не рассчитаны, а NoSQL-системы (которые здесь в основном обсуждают) как раз для этого и создавались. В этом весь смысл NoSQL, а вовсе не в избыточности RDBMS.