Комментарии 24
Обсуждать, надо полагать, будем сферического коня в вакууме?
«Не реляционные» пишется слитно.
Какова вводная?
где продолжение?
O MapReduce = www.osp.ru/os/2009/02/7322603/
Технологию MapReduce использует InterSystems — разработчик СУБД Cache
НЛО прилетело и опубликовало эту надпись здесь
Насчёт того, что InterSystems использует MapReduce — я несколько поторопился, прошу меня извинить. Но в Cache заложена база для организации распределённых вычислений — это и ECP и поддержка OpenVMS.
А зачем они это сделали — это вопрос к ним, может быть для того, что бы я мог выполнить свой дипломный проект и распределёно посчитать систолические матричные структуры :)))
А зачем они это сделали — это вопрос к ним, может быть для того, что бы я мог выполнить свой дипломный проект и распределёно посчитать систолические матричные структуры :)))
Как-то всё сумбурно. В одну кучу слились регекспы для парсинга объявлений и слишком общее описание способа хранения этой структуры. Я так понимаю, после парсинга «человеческого объявления» получается xml? И храните его в СУБД Cache?
Вообще было бы интересно почитать про Cache. Я так и не понял в чем его преимущество перед реляционной моделью, если вообще такое преимущество есть.
Вообще было бы интересно почитать про Cache. Я так и не понял в чем его преимущество перед реляционной моделью, если вообще такое преимущество есть.
«и слишком общее описание способа хранения этой структуры» — я описал конкретный используемое мной способ хранения (конечно структура представлена сокращённо).
В Cache xml не хранится. Дело в том что любой xml — можно отобразить в глобал но не любой глобал — можно отобразить в xml. Поэтому xml — используется только как тело пост запроса (ответа). В самом Cache данные так и хранятся — в дереве.
Если действительно интересно прочитать про каше — то я опишу механизмы хранения данных и индексов используемые мной.
В Cache xml не хранится. Дело в том что любой xml — можно отобразить в глобал но не любой глобал — можно отобразить в xml. Поэтому xml — используется только как тело пост запроса (ответа). В самом Cache данные так и хранятся — в дереве.
Если действительно интересно прочитать про каше — то я опишу механизмы хранения данных и индексов используемые мной.
Было бы интересно взглянуть. Я вчера после прочтения статьи побродил по оффсайту, почитал обзоры, немного документацию. В обзорах, как и у всех, пишут «мощная, быстрая, надежная», что ни капли не отражает насколько же каше мощная и быстрая. Техдокументацию читать слишком долго, чтобы получить общее представление. Более-менее сложилось впечатление по аналитическим и технологическим обзорам, неплоха еще статья на citforum. Думаю, стоит как-нибудь самому поиграться, пощупать вживую.
p.s. раньше слышал о Cache, но думал что это что-то мелкое, альтернативное и совсем непригодное к боевому применению.
p.s. раньше слышал о Cache, но думал что это что-то мелкое, альтернативное и совсем непригодное к боевому применению.
каше ровно на столько мощная быстрая и надёжная — насколько умело её использовать (скажу по себе — используем мы её ещё недостаточно умело)
Можешь зайти на сайт — и посмотреть.
А в блоге буду продолжать писать.
Можешь зайти на сайт — и посмотреть.
А в блоге буду продолжать писать.
Симпатично, разве что анимированные баннеры раздражают. Радует структурированность. Самое интересное по нашему вопросу — поиск, скорей туда. На выбор предоставляется чуть менее десятка стандартных тегов: марка, модель, цвет, цена, и т.п. Почему бы тут не использовать обычную реляционную БД? К полнотекстовому поиску нареканий нет — работает быстро, выдает правильно.
Фичей при поиске является отображение всех возможных значений. Например, при поиске по цвету, выдаются возможные цвета с кол-вом объявлений: белый, черный и т.д. Удобно. Наверное здесь возможности Cache пригодились. Но то же самое можно сделать и с реляционной базой.
Фичей при поиске является отображение всех возможных значений. Например, при поиске по цвету, выдаются возможные цвета с кол-вом объявлений: белый, черный и т.д. Удобно. Наверное здесь возможности Cache пригодились. Но то же самое можно сделать и с реляционной базой.
в твоём блоге про рекурсию и иерархию привёл пример работы с каше
Очень интересно устроена субд… проверки орфографии :)
Она там не то что древовидная, а дерево-кластерно-кольцевая( вы можете начать проверку слова с конца(кольцо), или по корню(кластер))
Либо самый часто используемый пример — AST
с учетом что в нодах, вообще-то, можно хранить все что угодно
Она там не то что древовидная, а дерево-кластерно-кольцевая( вы можете начать проверку слова с конца(кольцо), или по корню(кластер))
Либо самый часто используемый пример — AST
с учетом что в нодах, вообще-то, можно хранить все что угодно
В нодах действительно можно хранить всё что угодно — в глобалах Каше хранятся все коды классов скомпилированных и нескомпилированных программ. По большому счёту кроме деревьев там больше ничего нет. Хотя не имею личного опыта работы с ABS (Каше не основывается на абстрактных синтаксических деревьях) — может кто с ними (ABS) работал? Поделитесь опытом.
Лучшее применение ASP — репозитарий, точнее ресолв адресов.
например GET bla.bla.14.2.bla.bla.0 — node #…
часто приходилось работать с SNMP сервисами, а там при запросах километровые пути запрашиваего элемента…
технически — на каждом уровне сидит BSP который говорит что A — налево, а B- направо, а далее на дерево символа номер два и так далее
если кому интересно решение доступное обществености(С++) сам класс, использование
©Kashey лет 8 назад
например GET bla.bla.14.2.bla.bla.0 — node #…
часто приходилось работать с SNMP сервисами, а там при запросах километровые пути запрашиваего элемента…
технически — на каждом уровне сидит BSP который говорит что A — налево, а B- направо, а далее на дерево символа номер два и так далее
если кому интересно решение доступное обществености(С++) сам класс, использование
©Kashey лет 8 назад
а есть мысли и наработки по поводу использования ABS для реализации полнотекстового поиска?
Храним слово в AST, из него ссылка на нормальную форму слова(именительный падеж и тому подобное)+флаги формы.
Далее храним уже малек в другом формате AST документ.
Бьем по предложением и другой пункции( почти как Сишный код распарсиваем ), в нодах — ссылки на нормальную форму.
Отдельно храним lookup слово-документ
ИМХО AST хорош для поиска слова или пути, а также для сборки-разборки различных синтаксических конструкций.
Полнотекстовый поиск на его формате лучше не делать(ИМХО)
Далее храним уже малек в другом формате AST документ.
Бьем по предложением и другой пункции( почти как Сишный код распарсиваем ), в нодах — ссылки на нормальную форму.
Отдельно храним lookup слово-документ
ИМХО AST хорош для поиска слова или пути, а также для сборки-разборки различных синтаксических конструкций.
Полнотекстовый поиск на его формате лучше не делать(ИМХО)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Древовидные СУБД