скачал, за ссылку спасибо, обязательно сырцы гляну… но боюсь увязнуть ;)
>А если каталог из очень большого кол-ва элементов? Я имел ввиду базы, где ВСЕ хранится в виде графа.
то под каталог выделится еще один пул и поиск будет происходить в следующем пуле и т.д.
только вот мне приходит идея в каталоге использовать списковые структуры.
спасибо за идею… Это будет медленнее, но вставка будет быстрее, что существенно при больших объемах. Как ты на это смотришь? Так будет быстрее происходить вставка данных. Все должно быть отсортированно. Постараюсь выложить черновики структур.
я изобретаю веловипед — и я это понимаю,
но каждый изобретатель велосипеда считает, что его велосипед — самый лучший…
расскажу одну историю: у моего отца в НИИ в 70-е годы один инженер изобретал малолитражный самолет. Все сотрудники над ним смеялись и говорили, что зачем он это делает, ведь для этого есть специализированные авиционные НИИ. Он отвечал, что они ничего не понимают… И, он построил его.
может у меня, ничего не получится, и у нас любят смеяться и обливать грязью — это я заметил еще давно, но лучше пытаться что-то делать, чем сидеть и критиковать изобретателей. Кстати еще ни один из критиков не дал ни одной умной мысли.
согл, стереотипы не отнять. Хотя не надо говорить за всю нацию, кому надо — изучают что-то новое. Ну, у нас, например, тоже есть свои минусы: В одном топике стал рассказывать про основы HiLoad, так все дельные комменты заминусовали. А за всякую ерунду в оффтопе — плюсуют… Что ни говори — а народ странный.
спасибо за ссылку — посмотрю,
хочу сделать быстрое и красивое (не знаю на сколько оно таким получится) решение. Может какой-то функционал и порежу.
Думаю, надо отталкиваться от назначения. В данном случае моя БД будет предназначена для хранения малоизменяющихся иерархических справочников, извлечения которых нужно быстро.
Для этого и придуманы неименованные ключи (куча одинаковых похожих данных). Какие основные операции нужны для извлечения: извлечь данные по ключу, извлечь группу данных по ключу.
на счет масштабирования, пока не задумывался, очевидно буду решать проблему по аналогии масштабирования мемкешей. часть данных пихать в один сервер, часть в другой. а каталог делать общий на все сервера. по запросу смотрим каталог и запрашиваются данные с того сервера,
схема прорабатывается, есть идеи, — с удовольствием выслушаю!
на мой взгляд: структура будет храниться в виде массива взаимосвязанных нод. (связь по номеру индекса в массиве)
в массиве бедет ссылка на адресс данных в пуле днных.
масссив будет расширяемым, т.е. таких массивов будет несколько, по одному на выделяемый пул.
поиск ноды по иерархическому каталогу. Каталог один на всю БД (думаю его должно хватить...)
дословно — каталог — это что-то типа индекса иммен, ноды — это взаимосвязаные иерархические структуры, указывающие на данные, данные лежат в отдельном пуле.
я не силен в руби, про AR и DM услышал лет пять назад, когда столкнулся с дотнетом. Возможно это все разрабатывалось параллельно. Да, какие-то наработки DM были и в Java.
кому возня?
для конечного пользователя — это фиолетово (если клиент реализован правильно).
ты же не страдаешь от того, что в MySQL протокол идет дублирование передачи информации?
NoSQL базы, видно не хватает производительности SQL
в HiLoad проектах на фронтах и так JOIN не используется, тогда смысл RMDB теряется…
вот люди и ищут альтернативные решения…
а, что касается ActiveRecord и Datamapper пошли от великого и могучего ООП, с легкой подачи от Microsoft
>P.S. Вчера купил книгу по C#. Скорее всего, правильно сделал.
думаю, что выброшенные деньги, правда, если не хочешь сделаться промозглым Виндовозником.
я изучаю С++ два года, и каждый раз открываю в нем что-то новое… Выбор С++ — это выбор времени, когда РНР или Питона уже по каким-то причинам (как правило это производительность) становится не хватать.
>А если каталог из очень большого кол-ва элементов? Я имел ввиду базы, где ВСЕ хранится в виде графа.
то под каталог выделится еще один пул и поиск будет происходить в следующем пуле и т.д.
только вот мне приходит идея в каталоге использовать списковые структуры.
спасибо за идею… Это будет медленнее, но вставка будет быстрее, что существенно при больших объемах. Как ты на это смотришь? Так будет быстрее происходить вставка данных. Все должно быть отсортированно. Постараюсь выложить черновики структур.
но каждый изобретатель велосипеда считает, что его велосипед — самый лучший…
расскажу одну историю: у моего отца в НИИ в 70-е годы один инженер изобретал малолитражный самолет. Все сотрудники над ним смеялись и говорили, что зачем он это делает, ведь для этого есть специализированные авиционные НИИ. Он отвечал, что они ничего не понимают… И, он построил его.
может у меня, ничего не получится, и у нас любят смеяться и обливать грязью — это я заметил еще давно, но лучше пытаться что-то делать, чем сидеть и критиковать изобретателей. Кстати еще ни один из критиков не дал ни одной умной мысли.
спасибо за ссылку — посмотрю,
хочу сделать быстрое и красивое (не знаю на сколько оно таким получится) решение. Может какой-то функционал и порежу.
Думаю, надо отталкиваться от назначения. В данном случае моя БД будет предназначена для хранения малоизменяющихся иерархических справочников, извлечения которых нужно быстро.
Для этого и придуманы неименованные ключи (куча одинаковых похожих данных). Какие основные операции нужны для извлечения: извлечь данные по ключу, извлечь группу данных по ключу.
на счет масштабирования, пока не задумывался, очевидно буду решать проблему по аналогии масштабирования мемкешей. часть данных пихать в один сервер, часть в другой. а каталог делать общий на все сервера. по запросу смотрим каталог и запрашиваются данные с того сервера,
следующий этам — масштабирование.
я удаляюсь — дела семейные…
спасибо за честность.
на мой взгляд: структура будет храниться в виде массива взаимосвязанных нод. (связь по номеру индекса в массиве)
в массиве бедет ссылка на адресс данных в пуле днных.
масссив будет расширяемым, т.е. таких массивов будет несколько, по одному на выделяемый пул.
поиск ноды по иерархическому каталогу. Каталог один на всю БД (думаю его должно хватить...)
дословно — каталог — это что-то типа индекса иммен, ноды — это взаимосвязаные иерархические структуры, указывающие на данные, данные лежат в отдельном пуле.
и где тут реляционная структура?
внутренняя структура хранения прорабатывается,
наброски протокола выложил.
есть желание высказать мнение?
для конечного пользователя — это фиолетово (если клиент реализован правильно).
ты же не страдаешь от того, что в MySQL протокол идет дублирование передачи информации?
NoSQL базы, видно не хватает производительности SQL
в HiLoad проектах на фронтах и так JOIN не используется, тогда смысл RMDB теряется…
вот люди и ищут альтернативные решения…
а, что касается ActiveRecord и Datamapper пошли от великого и могучего ООП, с легкой подачи от Microsoft
думаю пока
давно изучено… тормоз
до этого использовал svn
сам курил эти функции, но пока применения не нашел
спасибо за статью
С++ — это основа-основ
все основные Опенсоурсы реализованы на Си/С++
все гуру по ООП начинали с С++
думаю, что выброшенные деньги, правда, если не хочешь сделаться промозглым Виндовозником.
я изучаю С++ два года, и каждый раз открываю в нем что-то новое… Выбор С++ — это выбор времени, когда РНР или Питона уже по каким-то причинам (как правило это производительность) становится не хватать.