а, вообще метод расчета очень похож на формирование матрицы расстояний в многомерном пространстве.
расчитываем расстояния меджу точками (критерии предпочтений).
Какие точки ближе всего, те — наши Друзья :)
тут выбор невелик: Энтропия регрессии:
либо сложность алгоритма, либо малоэффективный обсчет.
вообще-то все численные алгоритмы можно преспокойно обсчитать в бэдграундовом процессе, даже на отдельном сервере используя С++ и пара миллионов пользователей не будет пределом
а РНР использовать фронтэндом, для чего он впрочем и предназначен.
на эту цитату я обратил внимание в самом начале, и вот к ней комментарий
«если нужна производительность, то нужно отказаться от потоков»
конечно, потоки — это круто, это стандарт программирования на С++, я не гуру в С++, но как-то мы с коллегами профайлили проект, и оказалось, что простой printf на 20% производительнее потоков.
у современных тинейджеров и по 250 друзей не предел (на примере своих детей и их друзей)…
добавляют всех, кто постучится… а может, чтоб показать — какие они крутые и общительные.
а вот вставка элемента в существующую структуру будет помедленней. Действительно, потребуется дополнительное время на просмотра списка дочерних элементов Node, и встака в него данного элемента.
Сортировка, очевидно потребуется только один раз — при создании списка Node нового уровня (вставляем элемент и подэлементы).
Думаю, изменение и удаление не очень частые операции. Я делал упор на выборку.
Вставка нового элемента будет относительно быстро: встака элемента в список Dir + добавление нового элемента (вместо из пула ) Node + сами данные (вместо из пула )
Удаление элемента — операция специфическая, удаление элемента из 2BIdx труда не представляет. Освобождение ячейки в Dir — надо память как-то вернуть в пул. В идеале, если это был последний элемент, то без проблем. Но, идеала не бывает, по этому необходимо учитывать сегментированные куски памяти. Можно на них забить (учитывть только %%) и, например при сегментированности в 30% просто тупо восстановить данные с диска (потеря производительности на 1 транзакции). Тут конечно надо будет эксперементировать.
Ну и конечно же вылезает проблема сегментации в пуле Data.
>Есть опыт работу с иерархическими базами, и возможно мог бы помочь.
буду иметь ввиду
>При каких условиях(соотношение чтения/записи, объем и характер данных, глубина иерархии) ставится задача обойти mySQL?
пока такие критерии:
выборка на чтение, глубина иерархии 2-3, записей 1-го уровня 10 000.
может у тебя будут идеи по сравнению. Я честно говоря, пока слабо представляю. Когда я делал сравнения Sedna и MySQL, то сравнивал по выборки. Со вставками в Sedna — проблемы, как у всякой древовидной БД (native XML)
может в скором и перейдем на одну из систем CI
ну и какой же урод хранит бинарники в свн? Senior Programmer говоришь?
нет на него нашего начальника отдела!!!
расчитываем расстояния меджу точками (критерии предпочтений).
Какие точки ближе всего, те — наши Друзья :)
либо сложность алгоритма, либо малоэффективный обсчет.
вообще-то все численные алгоритмы можно преспокойно обсчитать в бэдграундовом процессе, даже на отдельном сервере используя С++ и пара миллионов пользователей не будет пределом
а РНР использовать фронтэндом, для чего он впрочем и предназначен.
но все равно приятно,
что статистический анализ хоть кто-то на практике применяет.
а матан — Математический Анализ.
разделяй и властвуй!
врагу не пожелаешь лучшей доли.
но то убожество, которое читаешь в исходниках 1С
отвращает писать код кириллицей.
а можно пример на параллельность?
я как раз начал разрабатывать одно приложение
хочу, чтоб оно так же без сбоев работало под 64
кстати если интересно, то можете заглянуть в мой персональный блог и посмотреть наброски.
хотелось бы услышать мнение опытного специалиста
«если нужна производительность, то нужно отказаться от потоков»
конечно, потоки — это круто, это стандарт программирования на С++, я не гуру в С++, но как-то мы с коллегами профайлили проект, и оказалось, что простой printf на 20% производительнее потоков.
добавляют всех, кто постучится… а может, чтоб показать — какие они крутые и общительные.
Сортировка, очевидно потребуется только один раз — при создании списка Node нового уровня (вставляем элемент и подэлементы).
Вставка нового элемента будет относительно быстро: встака элемента в список Dir + добавление нового элемента (вместо из пула ) Node + сами данные (вместо из пула )
Удаление элемента — операция специфическая, удаление элемента из 2BIdx труда не представляет. Освобождение ячейки в Dir — надо память как-то вернуть в пул. В идеале, если это был последний элемент, то без проблем. Но, идеала не бывает, по этому необходимо учитывать сегментированные куски памяти. Можно на них забить (учитывть только %%) и, например при сегментированности в 30% просто тупо восстановить данные с диска (потеря производительности на 1 транзакции). Тут конечно надо будет эксперементировать.
Ну и конечно же вылезает проблема сегментации в пуле Data.
буду иметь ввиду
>При каких условиях(соотношение чтения/записи, объем и характер данных, глубина иерархии) ставится задача обойти mySQL?
пока такие критерии:
выборка на чтение, глубина иерархии 2-3, записей 1-го уровня 10 000.
может у тебя будут идеи по сравнению. Я честно говоря, пока слабо представляю. Когда я делал сравнения Sedna и MySQL, то сравнивал по выборки. Со вставками в Sedna — проблемы, как у всякой древовидной БД (native XML)
вчера почвилась первая строчка кода