Comments 37
>>почему изобретаем велосипед?
>>да, скучно стало… надо освоить новые технологии.
А почему бы тогда не изучить, например, nested sets или иерархические бд? Например, Caché.
Ничего нового или особенного не увидел, и даже не увидел нормально проработанной структуры.
>>да, скучно стало… надо освоить новые технологии.
А почему бы тогда не изучить, например, nested sets или иерархические бд? Например, Caché.
Ничего нового или особенного не увидел, и даже не увидел нормально проработанной структуры.
>А почему бы тогда не изучить, например, nested sets или иерархические бд?
давно изучено… тормоз
давно изучено… тормоз
структуры чего?
внутренняя структура хранения прорабатывается,
наброски протокола выложил.
есть желание высказать мнение?
внутренняя структура хранения прорабатывается,
наброски протокола выложил.
есть желание высказать мнение?
Структура дерева как будет храниться? Где и какие будут линки на верхний и дочерние узлы?
В том виде как расписано сейчас это вообще выходит какая-то обычная реляционная база с уникальным индексом, и доп.полем, хранящем сконкатенированные индексы родителей.
В том виде как расписано сейчас это вообще выходит какая-то обычная реляционная база с уникальным индексом, и доп.полем, хранящем сконкатенированные индексы родителей.
схема прорабатывается, есть идеи, — с удовольствием выслушаю!
на мой взгляд: структура будет храниться в виде массива взаимосвязанных нод. (связь по номеру индекса в массиве)
в массиве бедет ссылка на адресс данных в пуле днных.
масссив будет расширяемым, т.е. таких массивов будет несколько, по одному на выделяемый пул.
поиск ноды по иерархическому каталогу. Каталог один на всю БД (думаю его должно хватить...)
дословно — каталог — это что-то типа индекса иммен, ноды — это взаимосвязаные иерархические структуры, указывающие на данные, данные лежат в отдельном пуле.
и где тут реляционная структура?
на мой взгляд: структура будет храниться в виде массива взаимосвязанных нод. (связь по номеру индекса в массиве)
в массиве бедет ссылка на адресс данных в пуле днных.
масссив будет расширяемым, т.е. таких массивов будет несколько, по одному на выделяемый пул.
поиск ноды по иерархическому каталогу. Каталог один на всю БД (думаю его должно хватить...)
дословно — каталог — это что-то типа индекса иммен, ноды — это взаимосвязаные иерархические структуры, указывающие на данные, данные лежат в отдельном пуле.
и где тут реляционная структура?
Имелся ввиду этот пост? Я объясню почему то, что я вижу мне не нравится изначально:
Вообще, если тема все еще интересна, то прошу с вопросами в личку. Есть опыт работу с иерархическими базами, и возможно мог бы помочь. Но мне вполне хватает мощностей, имеющихся субд(для высоконагруженных использую оракл), которые изделиями «на коленке» не обогнать.
- Не расписана схема хранения, т.к. просто «хранение в массиве» это ни о чем не говорит: массив — структура горизонтальная, в иерархических бд вообще достигается сама иерархичность за счет определенной избыточности, благодаря которой увеличивается скорость обработки операций целыми ветвями.
- массив взаимосвязанных нод — если читать дословно, то это тоже самое, что просто таблица состоящая из линка на данные, поле родителя и поле полного пути. Поясните, как именно будут строиться деревья?
- Каким образом будут выполняться операции выборки/изменения ветвей?
- При каких условиях(соотношение чтения/записи, объем и характер данных, глубина иерархии) ставится задача обойти mySQL?
Вообще, если тема все еще интересна, то прошу с вопросами в личку. Есть опыт работу с иерархическими базами, и возможно мог бы помочь. Но мне вполне хватает мощностей, имеющихся субд(для высоконагруженных использую оракл), которые изделиями «на коленке» не обогнать.
Сорри, поспешно написал, не заметив топика.
>Есть опыт работу с иерархическими базами, и возможно мог бы помочь.
буду иметь ввиду
>При каких условиях(соотношение чтения/записи, объем и характер данных, глубина иерархии) ставится задача обойти mySQL?
пока такие критерии:
выборка на чтение, глубина иерархии 2-3, записей 1-го уровня 10 000.
может у тебя будут идеи по сравнению. Я честно говоря, пока слабо представляю. Когда я делал сравнения Sedna и MySQL, то сравнивал по выборки. Со вставками в Sedna — проблемы, как у всякой древовидной БД (native XML)
буду иметь ввиду
>При каких условиях(соотношение чтения/записи, объем и характер данных, глубина иерархии) ставится задача обойти mySQL?
пока такие критерии:
выборка на чтение, глубина иерархии 2-3, записей 1-го уровня 10 000.
может у тебя будут идеи по сравнению. Я честно говоря, пока слабо представляю. Когда я делал сравнения Sedna и MySQL, то сравнивал по выборки. Со вставками в Sedna — проблемы, как у всякой древовидной БД (native XML)
хочу добиться 10 – 20 тысяч операций в секунду на чтение
распишу хранение информации чуть позже.
см мой сл пост, хранение расписал.
А кто вопросы задавал?
а зачем заморочки с вложенными деревьями если всё равно это можно хранить как одно имя вида «A.B.C»?
что-то последнее время бум прямо какойто на NoSQL базы. или я просто чего-то не замечал… И всякие ActiveRecord и Datamapper, с чего вдруг такой бум на все этом?
честно говоря почему бум: хз…
NoSQL базы, видно не хватает производительности SQL
в HiLoad проектах на фронтах и так JOIN не используется, тогда смысл RMDB теряется…
вот люди и ищут альтернативные решения…
а, что касается ActiveRecord и Datamapper пошли от великого и могучего ООП, с легкой подачи от Microsoft
NoSQL базы, видно не хватает производительности SQL
в HiLoad проектах на фронтах и так JOIN не используется, тогда смысл RMDB теряется…
вот люди и ищут альтернативные решения…
а, что касается ActiveRecord и Datamapper пошли от великого и могучего ООП, с легкой подачи от Microsoft
эм… поздравляю, ты изобрёл файловую систему х)
я изобретаю веловипед — и я это понимаю,
но каждый изобретатель велосипеда считает, что его велосипед — самый лучший…
расскажу одну историю: у моего отца в НИИ в 70-е годы один инженер изобретал малолитражный самолет. Все сотрудники над ним смеялись и говорили, что зачем он это делает, ведь для этого есть специализированные авиционные НИИ. Он отвечал, что они ничего не понимают… И, он построил его.
может у меня, ничего не получится, и у нас любят смеяться и обливать грязью — это я заметил еще давно, но лучше пытаться что-то делать, чем сидеть и критиковать изобретателей. Кстати еще ни один из критиков не дал ни одной умной мысли.
но каждый изобретатель велосипеда считает, что его велосипед — самый лучший…
расскажу одну историю: у моего отца в НИИ в 70-е годы один инженер изобретал малолитражный самолет. Все сотрудники над ним смеялись и говорили, что зачем он это делает, ведь для этого есть специализированные авиционные НИИ. Он отвечал, что они ничего не понимают… И, он построил его.
может у меня, ничего не получится, и у нас любят смеяться и обливать грязью — это я заметил еще давно, но лучше пытаться что-то делать, чем сидеть и критиковать изобретателей. Кстати еще ни один из критиков не дал ни одной умной мысли.
Графовые DB — очень перспективное направление, имхо. Думаю, вам стоит посмотреть исходники neo4j: neo4j.org/download
Интересно, как вы решите проблему репликации. Master-slave, прям скажем, — не самый удачный вариант.
На западе во всю разрабатывают NOSQL базы, строят дата-центры для облачных вычислений, изобретают новые языки программирования и т.п. А у нас только и слышно: «php+mysql, php+mysql, ...» Удивительно, как нация, славившаяся в мире свои образованием и разумом, не пытается изучать новые технологии и не пытается взглянуть на решение привычных проблем по-новому.
Интересно, как вы решите проблему репликации. Master-slave, прям скажем, — не самый удачный вариант.
На западе во всю разрабатывают NOSQL базы, строят дата-центры для облачных вычислений, изобретают новые языки программирования и т.п. А у нас только и слышно: «php+mysql, php+mysql, ...» Удивительно, как нация, славившаяся в мире свои образованием и разумом, не пытается изучать новые технологии и не пытается взглянуть на решение привычных проблем по-новому.
Вот так вот лихо сразу обо всей нации…
Абсолютно согласен, что излишний консерватизм и отсутсвие изменений в подходах мягко намекает на закат. Но ведь и у нас используются новые фишки.
Все начинают с распространненных вещей. Задают вопросы, рассказывают о запланированных мегапроектах. Получается иллюзия шумихи вокруг чего-то. Но по мере накопления опыта используются новые подходы. Только статей и рассказов об этом меньше — продвинутые разработчики просто берут и делают новое, экспериментируют, начинают с начала. И выхлоп у них больше. Только про них не очень слышно =)
Все начинают с распространненных вещей. Задают вопросы, рассказывают о запланированных мегапроектах. Получается иллюзия шумихи вокруг чего-то. Но по мере накопления опыта используются новые подходы. Только статей и рассказов об этом меньше — продвинутые разработчики просто берут и делают новое, экспериментируют, начинают с начала. И выхлоп у них больше. Только про них не очень слышно =)
согл, стереотипы не отнять. Хотя не надо говорить за всю нацию, кому надо — изучают что-то новое. Ну, у нас, например, тоже есть свои минусы: В одном топике стал рассказывать про основы HiLoad, так все дельные комменты заминусовали. А за всякую ерунду в оффтопе — плюсуют… Что ни говори — а народ странный.
спасибо за ссылку — посмотрю,
хочу сделать быстрое и красивое (не знаю на сколько оно таким получится) решение. Может какой-то функционал и порежу.
Думаю, надо отталкиваться от назначения. В данном случае моя БД будет предназначена для хранения малоизменяющихся иерархических справочников, извлечения которых нужно быстро.
Для этого и придуманы неименованные ключи (куча одинаковых похожих данных). Какие основные операции нужны для извлечения: извлечь данные по ключу, извлечь группу данных по ключу.
на счет масштабирования, пока не задумывался, очевидно буду решать проблему по аналогии масштабирования мемкешей. часть данных пихать в один сервер, часть в другой. а каталог делать общий на все сервера. по запросу смотрим каталог и запрашиваются данные с того сервера,
спасибо за ссылку — посмотрю,
хочу сделать быстрое и красивое (не знаю на сколько оно таким получится) решение. Может какой-то функционал и порежу.
Думаю, надо отталкиваться от назначения. В данном случае моя БД будет предназначена для хранения малоизменяющихся иерархических справочников, извлечения которых нужно быстро.
Для этого и придуманы неименованные ключи (куча одинаковых похожих данных). Какие основные операции нужны для извлечения: извлечь данные по ключу, извлечь группу данных по ключу.
на счет масштабирования, пока не задумывался, очевидно буду решать проблему по аналогии масштабирования мемкешей. часть данных пихать в один сервер, часть в другой. а каталог делать общий на все сервера. по запросу смотрим каталог и запрашиваются данные с того сервера,
А если каталог из очень большого кол-ва элементов? Я имел ввиду базы, где ВСЕ хранится в виде графа. При программировании, к примеру социальной сети, это будет очень удобно, а также легко подаваться изменениям.
Как расшаривать такое по многим серверам так просто в голову лично мне не приходит…
Кстати, посмотрите пример готового приложения в документации упомянутой мною Neo4j: wiki.neo4j.org/content/IMDB_Example
Как расшаривать такое по многим серверам так просто в голову лично мне не приходит…
Кстати, посмотрите пример готового приложения в документации упомянутой мною Neo4j: wiki.neo4j.org/content/IMDB_Example
скачал, за ссылку спасибо, обязательно сырцы гляну… но боюсь увязнуть ;)
>А если каталог из очень большого кол-ва элементов? Я имел ввиду базы, где ВСЕ хранится в виде графа.
то под каталог выделится еще один пул и поиск будет происходить в следующем пуле и т.д.
только вот мне приходит идея в каталоге использовать списковые структуры.
спасибо за идею… Это будет медленнее, но вставка будет быстрее, что существенно при больших объемах. Как ты на это смотришь? Так будет быстрее происходить вставка данных. Все должно быть отсортированно. Постараюсь выложить черновики структур.
>А если каталог из очень большого кол-ва элементов? Я имел ввиду базы, где ВСЕ хранится в виде графа.
то под каталог выделится еще один пул и поиск будет происходить в следующем пуле и т.д.
только вот мне приходит идея в каталоге использовать списковые структуры.
спасибо за идею… Это будет медленнее, но вставка будет быстрее, что существенно при больших объемах. Как ты на это смотришь? Так будет быстрее происходить вставка данных. Все должно быть отсортированно. Постараюсь выложить черновики структур.
кстати ты с neo возился?
интересная идея. Почему не сделать вместо целой системы — прослойку для хранения на редисе том же? То есть инфраструктура редиса, там кстати и можно использовать многие его уникальные фичи (в 1.2 особенно). Можно вполне как минимум прототип сделать, например, расширив один из лучших клиентских классов для работы с Redis — Rediska или PRedis (сегодня в твиттере был тест производительности — больше 200 000 запросов в секунду на распределенной на 4 узла системе — по моему, неплохо).
Исходники Редиса и Мемкеша изучаются, и положительный опыт будет перенят. Из мемкеша, я например хочу взять сетевую часть, а идея редиса: сохранение в файл путем форканья будет использована мной однозначно. Как альтернативную идею, можно использовать счетчик вставок и при достижении, например некоторого кол-ва вставок делать сохранение в мастер процессе (это если не будет использована тредовая модель).
Sign up to leave a comment.
еще один велосипед или TreeDb — NoSQL Database startup