|
|
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Да и вообще, для поиска можно (и даже нужно) использовать тот же Sphinx. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 11:40 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
servit Выше я приводил пример запроса для миллиона записей. не хочу умалять достоинство и труд разработчиков каше и прикладных систем, я лишь хочу предупредить от плохих эмоций тех людей, кто собирается работать с каше на больших объемах данных (миллионы и десятки миллионов записей) ПС. возможно, вы меня поправите, насколько мне известно, в США самая большая база обслуживает 4 млн ветеранов, на мой взгляд, это немного и у меня нет достоверной информации о том, что база используется в более масштабных нагруженных проектах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 12:22 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Васисуалий ПупкинсонmiksoftЯ бы предложил использовать EAV c нормализованными attribute-value. Тогда основная табличка сокращается всего до двух числовых полей.Сейчас в таблице есть три поля: attribute_id int value int user_id int Как это будет выглядеть в случае нормализованных attribute-value? Просто я честно говоря немного не в курсе что значит нормализованные..."нормализованные" - вынесенные в отдельную табличку-справочник. Т.е. таблички получатся примерно такие: Основная таблица: user_idattribute_value_id Справочник значений атрибутов: attribute_value_idattribute_idvaluedisplay_order Справочник атрибутов: attribute_idattributedisplay_orderЕсли атрибуты могут быть иерархическими, то в последнюю таблицу еще нужно добавить поле для указания родительского атрибута. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 12:47 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Васисуалий ПупкинсонЕсли нет, то подскажите плиз какие-нить бесплатные решения, очень уж не хочется на Оракл или SQL Server завязываться, т.к. лицензии стоят весьма ощутимо. Ну, можно посмотреть на бесплатный DB2 Express C, по идее задача как раз для него. Но вот оперативки в бесплатной лицензии может оказаться маловато - тут надо пробовать. Зато оптимизатор хороший :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 13:05 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 10.01.2011 20:08, Alexander Ryndin wrote: > BITMAP-индекс как раз отлично решает эту задачу с AND и OR. Это-то да. > Они также специально предназначен именно для случаев, когда количество различных > значений невелико. Тут подойдет даже рост, который имеет диапазон от 100 до 210. Как критерии будем объединять ? Сам-то понял, что спросил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 13:13 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
On 10.01.2011 22:29, Alexander Ryndin wrote: > Как критерии будем объединять ? > > Вопроса не понял. Но все равно можно расслабиться - человеку бесплатно нужно По одному критерию по его полю строим индекс (хотя бы и битмап), получаем быстрый поиск записей по этому критерию. Критериев много. Нужно найти пересечение множеств записей, удовлетворяющих каждому критерию. Как это делать ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:07 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
On 11.01.2011 2:21, Васисуалий Пупкинсон wrote: > Тогда правильный пример будет таким: > Т.е. на самом деле таким: > женщина > И > город - С.Петербург > И > не замужем > И ( цель знакомства = брак ИЛИ цель знакомства = романтические отношения ИЛИ цель знакомства = дружба ) > И > цвет волос - блондинка > И > NOT курит И тебе придётся таки трахаться с OR. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:10 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Вот это не хотите к базе прикрутить? Или я мимо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:11 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
On 11.01.2011 3:11, SERG1257 wrote: > Я бы начал с этого варианта не связываясь с EAV. Пустые значения хранится не Да пока проблема-то не в нём. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:12 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
On 11.01.2011 4:16, pilot911 wrote: > если так - то запрос должен выполняться очень быстро даже на миллионах записей Что заставляет тебя так думать ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:13 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 10.01.2011 22:29, Alexander Ryndin wrote: > Как критерии будем объединять ? > > Вопроса не понял. Но все равно можно расслабиться - человеку бесплатно нужно По одному критерию по его полю строим индекс (хотя бы и битмап), получаем быстрый поиск записей по этому критерию. Критериев много. Нужно найти пересечение множеств записей, удовлетворяющих каждому критерию. Как это делать ? Еще раз, для особо одаренных - STAR QUERY. Делался как раз под эту задачу, чтоб на сотнях миллионов записей как раз такие вот пересечения искать. Правда, если у автора данных кот наплакал (пара сотен тысяч), то это все суета вокруг дивана... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:21 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
MasterZiv И тебе придётся таки трахаться с OR. Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:22 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
а такс, вообще говоря, in==or ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:27 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovКажется, именно с проблемой выборок по большому количеству критериев призваны бороться GIS-расширения. Всякие там R-tree индексы и т.д... Почему бы не попробовать их?.. Очччень интересно было бы почитать, каким образом R-tree помогает селекать по куче атрибутов и вообще, как GIS относится к проблеме. Вот даже просто.... что-то типа "кажется, именно философия Канта призвана бороться со смертностью детей в Африке". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:40 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
ApexMasterZivOn 10.01.2011 22:29, Alexander Ryndin wrote: > Как критерии будем объединять ? > > Вопроса не понял. Но все равно можно расслабиться - человеку бесплатно нужно По одному критерию по его полю строим индекс (хотя бы и битмап), получаем быстрый поиск записей по этому критерию. Критериев много. Нужно найти пересечение множеств записей, удовлетворяющих каждому критерию. Как это делать ? Еще раз, для особо одаренных - STAR QUERY. Делался как раз под эту задачу, чтоб на сотнях миллионов записей как раз такие вот пересечения искать. Правда, если у автора данных кот наплакал (пара сотен тысяч), то это все суета вокруг дивана...Ага точно. Star Transformation Query. Упрощенно описано в документации . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:43 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
MasterZivИ тебе придётся таки трахаться с OR Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:48 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
softwarerОчччень интересно было бы почитать, каким образом R-tree помогает селекать по куче атрибутов и вообще, как GIS относится к проблеме. Понятия не имею, но вот есть один аффтар настаивает: http://tech.groups.yahoo.com/group/Firebird-Architect/message/11369 http://tech.groups.yahoo.com/group/Firebird-Architect/message/11381 Утверждает, что запрос с кучей index range scan по разным B-tree индексам сливает, а R-tree рулит со страшной силой. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 16:59 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovПонятия не имею, но вот есть один аффтар настаивает: Боюсь, эти ссылки без регистрации показывают пустой экран. Мм... настаивать он может сколько угодно. В принципе, конечно, R-tree действительно рулит, но только есть два момента: во-первых, оно рулит для поиска объектов, обладающих протяжённостью (то есть для запросов вида "покажи мне отрезки, хоть насколько-то пересекающиеся с отрезком (A, B)") а во-вторых, сколь мне помнится, многомерные R-индексы требуют задания всех атрибутов (ну или ведущих в списке - в общем аналогично B-tree). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 17:39 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
softwarerнастаивать он может сколько угодно Ну, он там приводит в пример как запрос класса Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. индексами при числе записей в таблице на уровне десятков миллионов. Условия в этом запросе мне сильно напомнили то, что говорит ТС, поэтому я и посоветовал ему обратить внимание на GiS. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 18:04 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovвыполняется на SQLite с его R-tree индексами намного быстрее чем на Firebird с B-tree Дык неудивительно. Но стоит выкинуть условие на какую-либо координату, и R-индекс займётся оральным сексом, что топикстартера вряд ли порадует :) Собственно, именно этот запрос и в случае аналогичного B-индекса cкорее всего неплохо отработает, и проявит бОльшую к выкидыванию не-первых координат. Суть r-индекса показана здесь . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 18:24 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Либо за приличные деньги использовать Oracle с bitmap indexes, либо эксперименитровать с PostgreSQL R-tree indexes. Оракловская имплементация R-tree индекса здесь бесполезна, поскольку ограничена 4 измерениями. У PostgreSQL такого искусственного ограничения вроде нет, но R-tree индексы жрут немерянно памяти, и я очень сомневаюсь наскольку эффективно они будут работать для вырожденных запросов (пропущенные измерения). Должно также сильно тормозить на вставку/модификацию. Попробуйте найти open source базу с поддержкой bitmap indexes. LusidDB вроде умеет это делать, но опять же это только для чтения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 19:24 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Погуглил немножко, интересно стало. Похоже, что R-tree индексы быстро теряют в производительности при росте числа измерений, и при 10-20 измерениях full scan для поиска данных становится быстрее ( и проще :^) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 19:40 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
SergSuperвобще странно, мне кажется что для 100 тыч записей полное сканирование должно занимать доли секунды может имеет смысл наиболее селективные атрибуты записывать в одну таблицу, делать простейший запрос, а потом проверять дополнительные атрибуты? Я тестил для 100 тыс. пользователей, у которых в среднем есть по 50 атрибутов. Поэтому получилось 5 миллионов записей. А на 100 тыс. записей думаю да, проблем не было бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 19:46 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Васисуалий Пупкинсон, Без EAV 100т строк с заполненными 50 полями (~1000байт) по объему 100МБ будет сидеть в кеше. Фулскан будет занимать миллисекунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 20:21 |
|
||
|
EAV с возможностью быстрой выборки по сложным условиям
|
|||
|---|---|---|---|
|
#18+
Васисуалий Пупкинсон, если вы использовали PostreSQL, то пробовали ли вы реализацию через GIN-индекс на intarray/hstore? Можно даже поверх 10052526 , а можно и без. F.15. intarray F.13. hstore F.15.1. intarray Functions and OperatorsThe @@ and ~~ operators test whether an array satisfies a query, which is expressed as a value of a specialized data type query_int. A query consists of integer values that are checked against the elements of the array, possibly combined using the operators & (AND), | (OR), and ! (NOT). Parentheses can be used as needed. For example, the query 1&(2|3) matches arrays that contain 1 and also contain either 2 or 3. для старта можно попробовать заиспользовать intarray для хранения ссылок на значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2011, 21:00 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=37052839&tid=1552724]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 159ms |

| 0 / 0 |
