Това е най-вече продължение на публикацията на @Anony-Mousse, която е доста точна.
Индексите трябва да се добавят към базата данни от потребителя. Понастоящем няма автоматично индексиране (тъй като всеки индекс ще изисква допълнителна памет и време за изграждане). -db.index е параметърът за това. Поддръжката за автоматично индексиране е в списъка с желания, но изисква внимателно настроени модели на разходите. При малък набор от данни или данни с големи размери, или когато потребителят изобщо не се нуждае от този тип заявки, добавянето на индекс ще има цена.
Базата данни ще препрати заявката към всеки индекс по ред. Печели първият индекс, който предлага ускорение. Ако нито един индекс не върне ускорена заявка, базата данни ще се върне към линейно сканиранеосвен ако не е дадено подсказката DatabaseQuery.HINT_OPTIMIZED_ONLY. В този случай ще бъде върнато null. Линейно сканиране може да бъде принудено чрез QueryUtil, което е най-вече полезно за индекси за тестване на единици.
M-Дърветата могат да работят с всяко числово разстояние, но ако разстоянието не е метрично, резултатите може да са неправилни. Трябва да се докладва грешка, ако функция за разстояние не отчете isMetric() като вярно.
R-Trees може да работи с всяка функция за разстояние, която прилага SpatialPrimitiveDistanceFunction, което по същество означава прилагане на долна граница на разстояние от точка до правоъгълник. Може да се намери долна граница за много функции за разстояние, но ефективността може да варира. Например, ъгловите разстояния ще се възползват много по-малко от правоъгълните страници, използвани от R-дървото.
Що се отнася до метода run. Предпочитаният подпис за обичайните методи за векторно пространство е
YourResultType run(Database database, Relation<V> relation)
Към момента базата данни може действително да бъде получена чрез relation.getDatabase(), но това може да се промени в бъдеще. Има редица ситуации, в които това е проблематично, а някои ситуации, в които в момента не могат да бъдат лесно отстранени, за съжаление. Както и да е, това е изричната форма, която е удобна за стартиране на алгоритмите от Java код, т.е. позволява ми да посоча коя връзка да използвам, вместо да се налага да използвам база данни, където това е единственото подходящо релация (така че се избира автоматично).
Имам планове да направя това още по-ясно в дългосрочен план, добавяйки изрична поддръжка за избор на подмножество от данни за обработка, а може би и на заявките. След това абстрактният родителски метод run ще се погрижи за това. Един автоматичен оптимизатор ще разчита на това: той първо ще направи заявка за всички алгоритми, които да бъдат изпълнени за техните изисквания, включително изисквания за заявка. Въз основа на заявките, набора от данни, наличната памет и т.н. оптимизаторът може да избере подходящи индекси и да предаде на алгоритъма подходящите методи за заявка. За да запазите run подписа прост, той вероятно ще се обработва чрез някои Instance класове и вместо това ще се използва повече фабричният шаблон. Но не се тревожи за това сега.
Ако искате да разберете защо имаме нужда от това, погледнете напр. алгоритми за откриване на геопространствени отклонения. Подписът, използван от SLOM например, е:
OutlierResult run(Database database, Relation<N> spatial, Relation<O> relation)
т.е. SLOM използва две релации две. Първата релация е пространствената връзка на екземплярите, напр. географски позиции. Второто отношение са действителните данни, напр. измервания. Географските позиции се използват, за да се определи кои екземпляри се очаква да бъдат подобни (но те също могат да бъдат например многоъгълници!), докато втората релация уточнява данните, които всъщност след това се сравняват за сходство.
person
Erich Schubert
schedule
14.10.2013
