История тарантула как раз и начиналась с Memcached. Первым подходом было прикрутить к мемкешеду снапшоты, чтобы не стартовать с пустым кэшем. Потом был сильвербокс — уже полностью свое решение с транзакциями, снапшотами и wal. И уже на замену ему вырос тарантул.
прелесть moose/mouse не в «птичьем» языке, а в meta — это очень мощный и удобный инструмент для метапрограммирования, с помощью которого можно творить очень классные вещи. плюс трейты, плюс не надо выдумывать свой велосипед для lazy_build. ну и всякий сахар их Moose::Exporter и Moose::Util
ну и остальное по мелочи
сеттеры-геттеры реально нужны — во-первых, некошерно лазить грязными рукими внутрь класса, во-вторых, они упрощают наследование. опять же coercion, хоть это и тормоз, но если отдавать себе отчет, что ты делаешь, можно аккуратно использовать.
есть замечание, что неплохо было-бы написать про управление партициями не через триггер, а через rule, и когда какой метод предпочтительней использовать
ну это и так прозрачно: все пишется в мастер-таблицу.
проблема в том, что партицировать можно по разному: на основании любой хэш функции (операторов больше-меньше для сравнимых типов; или, например, юзеров делим на две часть — мальчиков направо, девочек налево), еще как угодно. так что как ни крути, придется писать свою хэш-функцию и делать под нее свой синтаксис в create table. а зачем, если все уже есть?
плюс еще, что не бд не знает, что пора делать новую партицию — может быть куча вариантов: по времени, по количеству данных.
вроде бы вы смотрите только одинаковые шинглы, но не учитываете количество разных. хз, хорошо это или плохо, зависит от задачи. сформулируйте, условно на пальцах, что для вас похожие документы, т.к. это сильно влияет на алгоритмы. т.е. если вы ищите, к примеру, плагиат — это одно, а если новости об одном и том же, то несколько другое, от этого у будет зависеть мера.
а в пункте 9 вы пытаетесь делать кластеризацию, но, например, если A похоже на B, B похоже на C, но A не похоже на C, то A с С у вас не стростется. тоже от задачи зависит, хорошо это или плохо.
в общем, не понятно, какую задачу решает ваш алгоритм :)
Ой-ой, по моему вы что-то сильно путаете. Судя по всему, вы пытаетесь рассказать алгоритм, предложенный Fetterly et al. A Large-Scale Study of the Evolution of Web Pages, www2003. Никаких 84 хэш-функций там нет, это стандартное вычисление мегашинглов на основе вероятностного вычисления индекса Жаккарда (отсюда кстати и эмперическая оценка в 84 перестановки, которая (на память) дает погрешность в 15%). У Зеленкова и Сегаловича, как я понял, сам алгорим изложен не верно, да и у Fetterly очень кратко написано.
Прочитайте оригинал Broder et al, Syntactic Clustering of the Web, 1997 и еще статья 1993 про полиномы Рабина и сравните с тем, что вы написали. А по поводу мистических цифр — Broder et al, Min-Wise Independent Permutations 2000 и там по ссылкам.
И, кстати, при вычислении индекса жаккрада сложность не экспоненциальная, а полиномиальная (хотя это тоже плохо на больших коллекциях) :)
Небольшое замечание, почему в постгре нет SQL_CALC_FOUND_ROWS (что бы его не ругали). Постгря умеет использовать индексы для сортировки и выборок limit/offset, соотв. при выборке он может и не пройтись по всем полям, удовлетворяющим where.
На практике имеет смысл денормализовать по полям, которые используются в where.
История тарантула как раз и начиналась с Memcached. Первым подходом было прикрутить к мемкешеду снапшоты, чтобы не стартовать с пустым кэшем. Потом был сильвербокс — уже полностью свое решение с транзакциями, снапшотами и wal. И уже на замену ему вырос тарантул.
ну и остальное по мелочи
сеттеры-геттеры реально нужны — во-первых, некошерно лазить грязными рукими внутрь класса, во-вторых, они упрощают наследование. опять же coercion, хоть это и тормоз, но если отдавать себе отчет, что ты делаешь, можно аккуратно использовать.
но moose да, тормоз. в продакшен только mouse
— феймановские лекции по физике
alter table… inherits
проблема в том, что партицировать можно по разному: на основании любой хэш функции (операторов больше-меньше для сравнимых типов; или, например, юзеров делим на две часть — мальчиков направо, девочек налево), еще как угодно. так что как ни крути, придется писать свою хэш-функцию и делать под нее свой синтаксис в create table. а зачем, если все уже есть?
плюс еще, что не бд не знает, что пора делать новую партицию — может быть куча вариантов: по времени, по количеству данных.
а в пункте 9 вы пытаетесь делать кластеризацию, но, например, если A похоже на B, B похоже на C, но A не похоже на C, то A с С у вас не стростется. тоже от задачи зависит, хорошо это или плохо.
в общем, не понятно, какую задачу решает ваш алгоритм :)
Прочитайте оригинал Broder et al, Syntactic Clustering of the Web, 1997 и еще статья 1993 про полиномы Рабина и сравните с тем, что вы написали. А по поводу мистических цифр — Broder et al, Min-Wise Independent Permutations 2000 и там по ссылкам.
И, кстати, при вычислении индекса жаккрада сложность не экспоненциальная, а полиномиальная (хотя это тоже плохо на больших коллекциях) :)
На практике имеет смысл денормализовать по полям, которые используются в where.