Обновить
Комментарии 24
Обсуждать, надо полагать, будем сферического коня в вакууме?
Вижу конь перестает быть сферическим. Только вот.

>Ни для кого не секрет, что многие СУБД (тот же ORACLE и MSSQL) физически хранят данные в Б-деревьях

А данные обслуживают Б — садовники? :)
Просто резануло «физически» — физически лежит на накопителе.
Вижу исправление в названии, замечательно. Только вот почему тогда не обозвать топик «Реляционные СУБД»? Ведь как известно мозг человека хуже обрабатывает фразы с «не», чем без.
Похоже это публичный черновик :) ТС постепенно дописывает топик, глядишь к вечеру что-то оформится :)
Технологию MapReduce использует InterSystems — разработчик СУБД Cache
А каким образом они ее используют? И даже вопрос скорее — зачем ?? Ведь если уж использовать MapReduce, то для больших данных, и тогда при Reduce мы можем недополучить результаты с нескольких узлов обработки (теоретически). А что тогда? «sorry, your query couldn't be executed»?
Насчёт того, что InterSystems использует MapReduce — я несколько поторопился, прошу меня извинить. Но в Cache заложена база для организации распределённых вычислений — это и ECP и поддержка OpenVMS.
А зачем они это сделали — это вопрос к ним, может быть для того, что бы я мог выполнить свой дипломный проект и распределёно посчитать систолические матричные структуры :)))
Как-то всё сумбурно. В одну кучу слились регекспы для парсинга объявлений и слишком общее описание способа хранения этой структуры. Я так понимаю, после парсинга «человеческого объявления» получается xml? И храните его в СУБД Cache?
Вообще было бы интересно почитать про Cache. Я так и не понял в чем его преимущество перед реляционной моделью, если вообще такое преимущество есть.
«и слишком общее описание способа хранения этой структуры» — я описал конкретный используемое мной способ хранения (конечно структура представлена сокращённо).

В Cache xml не хранится. Дело в том что любой xml — можно отобразить в глобал но не любой глобал — можно отобразить в xml. Поэтому xml — используется только как тело пост запроса (ответа). В самом Cache данные так и хранятся — в дереве.

Если действительно интересно прочитать про каше — то я опишу механизмы хранения данных и индексов используемые мной.
Было бы интересно взглянуть. Я вчера после прочтения статьи побродил по оффсайту, почитал обзоры, немного документацию. В обзорах, как и у всех, пишут «мощная, быстрая, надежная», что ни капли не отражает насколько же каше мощная и быстрая. Техдокументацию читать слишком долго, чтобы получить общее представление. Более-менее сложилось впечатление по аналитическим и технологическим обзорам, неплоха еще статья на citforum. Думаю, стоит как-нибудь самому поиграться, пощупать вживую.

p.s. раньше слышал о Cache, но думал что это что-то мелкое, альтернативное и совсем непригодное к боевому применению.
каше ровно на столько мощная быстрая и надёжная — насколько умело её использовать (скажу по себе — используем мы её ещё недостаточно умело)
Можешь зайти на сайт — и посмотреть.
А в блоге буду продолжать писать.
Симпатично, разве что анимированные баннеры раздражают. Радует структурированность. Самое интересное по нашему вопросу — поиск, скорей туда. На выбор предоставляется чуть менее десятка стандартных тегов: марка, модель, цвет, цена, и т.п. Почему бы тут не использовать обычную реляционную БД? К полнотекстовому поиску нареканий нет — работает быстро, выдает правильно.
Фичей при поиске является отображение всех возможных значений. Например, при поиске по цвету, выдаются возможные цвета с кол-вом объявлений: белый, черный и т.д. Удобно. Наверное здесь возможности Cache пригодились. Но то же самое можно сделать и с реляционной базой.
какой полнотекстовый поиск? он же ещё не запущен — поясни
В расширенном поиске последний тег «полнотекстовый поиск».
в твоём блоге про рекурсию и иерархию привёл пример работы с каше
Очень интересно устроена субд… проверки орфографии :)
Она там не то что древовидная, а дерево-кластерно-кольцевая( вы можете начать проверку слова с конца(кольцо), или по корню(кластер))

Либо самый часто используемый пример — AST
с учетом что в нодах, вообще-то, можно хранить все что угодно
В нодах действительно можно хранить всё что угодно — в глобалах Каше хранятся все коды классов скомпилированных и нескомпилированных программ. По большому счёту кроме деревьев там больше ничего нет. Хотя не имею личного опыта работы с ABS (Каше не основывается на абстрактных синтаксических деревьях) — может кто с ними (ABS) работал? Поделитесь опытом.
Лучшее применение ASP — репозитарий, точнее ресолв адресов.
например GET bla.bla.14.2.bla.bla.0 — node #…
часто приходилось работать с SNMP сервисами, а там при запросах километровые пути запрашиваего элемента…

технически — на каждом уровне сидит BSP который говорит что A — налево, а B- направо, а далее на дерево символа номер два и так далее

если кому интересно решение доступное обществености(С++) сам класс, использование
©Kashey лет 8 назад
а есть мысли и наработки по поводу использования ABS для реализации полнотекстового поиска?
Храним слово в AST, из него ссылка на нормальную форму слова(именительный падеж и тому подобное)+флаги формы.
Далее храним уже малек в другом формате AST документ.
Бьем по предложением и другой пункции( почти как Сишный код распарсиваем ), в нодах — ссылки на нормальную форму.

Отдельно храним lookup слово-документ
ИМХО AST хорош для поиска слова или пути, а также для сборки-разборки различных синтаксических конструкций.

Полнотекстовый поиск на его формате лучше не делать(ИМХО)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.