<br><br><div class="gmail_quote">On Feb 4, 2008 12:08 PM, Sakai Openlife <<a href="mailto:sakai@openlifegrid.com">sakai@openlifegrid.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think this search idea also re-inforces my earlier call (already in<br>Mantis) that parcel data should be held grid side. Rather than the current<br>position of in the local prim store.<br></blockquote><div><br>in other words you are suggesting all the websites should hold their data in google cache as their primary content repository ?<br>
<br>how does yahoo get the content then ? we don't want monopolies :-)<br><br>indeed the search servers can and should have a *secondary* copy of the information. <br><br>But making them hold the *primary* copy IMHO makes that yet another bottleneck and maintenance load, alongside with the UGA.<br>
<br>I'm talking about a server to hold a few dozen millions of records and ~10-100 requests per second<br><br>/d<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>However the option of it being local should still be there as not every<br>application of the OpenSimulator will be an 'SL Like' style Grid.<-Perhaps<br>flagged in the .ini<br><br>It may also be beneficial to have a 'parcel' just for handling this things<br>
much like we have a grid server, as not to overwhelm existing services such<br>as GRID or USER.<br><br>Sakai Openlife<br><br>-----Original Message-----<br>From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a><br>
[mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of<br><a href="mailto:opensim-dev-request@lists.berlios.de">opensim-dev-request@lists.berlios.de</a><br>Sent: Monday, 4 February 2008 9:02 PM<br>
To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>Subject: Opensim-dev Digest, Vol 6, Issue 5<br><br>Send Opensim-dev mailing list submissions to<br> <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
<br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:opensim-dev-request@lists.berlios.de">opensim-dev-request@lists.berlios.de</a><br><br>You can reach the person managing the list at<br> <a href="mailto:opensim-dev-owner@lists.berlios.de">opensim-dev-owner@lists.berlios.de</a><br>
<br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Opensim-dev digest..."<br><br><br>Today's Topics:<br><br> 1. Search server DB schema (David Wendt JR.)<br> 2. Re: Search server DB schema (Justin Clark-Casey)<br>
3. Re: Search server DB schema (Dalien Talbot)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 3 Feb 2008 10:19:35 -0800 (PST)<br>From: "David Wendt JR." <<a href="mailto:dcrkid@yahoo.com">dcrkid@yahoo.com</a>><br>
Subject: [Opensim-dev] Search server DB schema<br>To: Opensim-dev mailing list <<a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>><br>Message-ID: <<a href="mailto:171180.25639.qm@web58314.mail.re3.yahoo.com">171180.25639.qm@web58314.mail.re3.yahoo.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br><br>Hello, OpenSim developers.<br><br> I have recently taken up OpenSim development. I'm writing plugins to<br>allow Search to work. I need your opinion on a database schema for storing<br>
the indexed search information for a hypothetical (so far) new grid service<br>"SearchServer".<br><br> I figure out for searching "Places", "Popular Places", and "Land Sales"<br>
we will need the following fields: Parcel UUID, Name, Description, LandArea,<br>Traffic, Region UUID, Region Maturity Flag, Region Parent Estate ID, Loc X,<br>Loc Y, Loc Z, Image UUID, ForSaleStatus, Category, ForSalePrice, AuctionID,<br>
Owner UUID, OwnerIsGroup Flag. Some of these fields won't be implemented for<br>a long time (especially ParentEstates) but it's good to have those anyway.<br><br> The "Classifieds" search tab requires these fields: Entry UUID, Name,<br>
Description, Publisher UUID, Publisher Parent Estate ID, Image UUID,<br>ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X, Loc Y, Loc Z,<br>MatureFlag.<br><br> The "Events" calendar search tab requires these fields: Event UUID,<br>
Name, Description, Publisher UUID, Publisher Parent Estate ID, Mature<br>Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc Y, Loc Z,<br>Cover Charge. The Event calendar also supports notifying people who opt-in,<br>
so it would also require another table with Event UUID and Subscribing<br>Avatar UUID.<br><br> New Search (which I don't forsee being able to implement until way<br>later) also requires sim object data. Object UUID, Parent Parcel UUID, Name,<br>
ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good enough.<br><br> Now I need your opinion on this schema. Is it a good idea to have each<br>type of searchable object in a separate table? Or would it be more feasible<br>
to have all the relevant fields in a single table "search" with an<br>"objecttype" enum to differentiate between the types?<br><br>From,<br> KMeist Hax<br><br><br><br><br><br>____________________________________________________________________________<br>
________<br>Be a better friend, newshound, and<br>know-it-all with Yahoo! Mobile. Try it now.<br><a href="http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ" target="_blank">http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ</a><br>
-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><a href="https://lists.berlios.de/pipermail/opensim-dev/attachments/20080203/15b30aed/attachment-0001.html" target="_blank">https://lists.berlios.de/pipermail/opensim-dev/attachments/20080203/15b30aed<br>
/attachment-0001.html</a><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 04 Feb 2008 08:29:26 +0000<br>From: Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>><br>
Subject: Re: [Opensim-dev] Search server DB schema<br>To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>Message-ID: <<a href="mailto:47A6CCE6.4020205@googlemail.com">47A6CCE6.4020205@googlemail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Hi David,<br><br>Personally, my instinct would be to have one table to hold all the<br>common fields between these searchable objects, and separate tables to<br>
hold the details specific to each.<br><br>However, this opinion is formed more by my desire for neatness (not<br>having lots of redundant attributes for search objects where certain<br>fields don't apply) than any knowledge about how this may affect<br>
performance.<br><br>Regards,<br><br>--<br>justincc<br><br>David Wendt JR. wrote:<br>> Hello, OpenSim developers.<br>><br>> I have recently taken up OpenSim development. I'm writing plugins<br>> to allow Search to work. I need your opinion on a database schema for<br>
> storing the indexed search information for a hypothetical (so far) new<br>> grid service "SearchServer".<br>><br>> I figure out for searching "Places", "Popular Places", and "Land<br>
> Sales" we will need the following fields: Parcel UUID, Name,<br>> Description, LandArea, Traffic, Region UUID, Region Maturity Flag,<br>> Region Parent Estate ID, Loc X, Loc Y, Loc Z, Image UUID,<br>> ForSaleStatus, Category, ForSalePrice, AuctionID, Owner UUID,<br>
> OwnerIsGroup Flag. Some of these fields won't be implemented for a<br>> long time (especially ParentEstates) but it's good to have those anyway.<br>><br>> The "Classifieds" search tab requires these fields: Entry UUID,<br>
> Name, Description, Publisher UUID, Publisher Parent Estate ID, Image<br>> UUID, ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X,<br>> Loc Y, Loc Z, MatureFlag.<br>><br>> The "Events" calendar search tab requires these fields: Event<br>
> UUID, Name, Description, Publisher UUID, Publisher Parent Estate ID,<br>> Mature Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc<br>> Y, Loc Z, Cover Charge. The Event calendar also supports notifying<br>
> people who opt-in, so it would also require another table with Event<br>> UUID and Subscribing Avatar UUID.<br>><br>> New Search (which I don't forsee being able to implement until way<br>> later) also requires sim object data. Object UUID, Parent Parcel UUID,<br>
> Name, ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good<br>> enough.<br>><br>> Now I need your opinion on this schema. Is it a good idea to have<br>> each type of searchable object in a separate table? Or would it be<br>
> more feasible to have all the relevant fields in a single table<br>> "search" with an "objecttype" enum to differentiate between the types?<br>><br>> From,<br>> KMeist Hax<br>><br>
> ------------------------------------------------------------------------<br>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try<br>> it now.<br>><br><<a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20" target="_blank">http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8<br>
HDtDypao8Wcj9tAcJ%20</a>><br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>><br><br><br>--<br>justincc<br>Justin Clark-Casey<br><br><br><br>------------------------------<br>
<br>Message: 3<br>Date: Mon, 4 Feb 2008 09:59:37 +0100<br>From: "Dalien Talbot" <<a href="mailto:dalienta@gmail.com">dalienta@gmail.com</a>><br>Subject: Re: [Opensim-dev] Search server DB schema<br>To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
Message-ID:<br> <<a href="mailto:970c50810802040059p6d7389dav6b6dc6db80154f37@mail.gmail.com">970c50810802040059p6d7389dav6b6dc6db80154f37@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br>
<br>David,<br><br>just curious - have you played with the non-relational methods of doing the<br>search ?<br><br>I've had a very good success with Xapian library - and it has bindings for<br>anything and everything (although - yick. this would mean one more native<br>
code lib in the code base).<br><br>But the upside is that it would allow for more flexible "google-like"<br>searches, imho - which is the very big plus. And you can allow quite a few<br>custom tags to be included into boolean search - even though it is not very<br>
fast to index, the convenience of working with it was extremely pleasing.<br><br>Another interesting beast is sphinx - I did not test it personally, but from<br>what they write here:<br><br><a href="http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text-search/" target="_blank">http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text<br>
-search/</a><br><br>It looks quite promising scalability-wise.<br><br>An engine which was theoretically very good (at least according to the<br>benchmarks that I've read) was zettair. However, playing with the code<br>
showed the quality of it is really "alpha" - sprinkled with assert's - and<br>not without a few bugs too :-) - so probably more of theoretical interest.<br><br>/d<br><br><br><br><br>On Feb 3, 2008 7:19 PM, David Wendt JR. <<a href="mailto:dcrkid@yahoo.com">dcrkid@yahoo.com</a>> wrote:<br>
<br>> Hello, OpenSim developers.<br>><br>> I have recently taken up OpenSim development. I'm writing plugins to<br>> allow Search to work. I need your opinion on a database schema for storing<br>> the indexed search information for a hypothetical (so far) new grid<br>
service<br>> "SearchServer".<br>><br>> I figure out for searching "Places", "Popular Places", and "Land<br>> Sales" we will need the following fields: Parcel UUID, Name, Description,<br>
> LandArea, Traffic, Region UUID, Region Maturity Flag, Region Parent Estate<br>> ID, Loc X, Loc Y, Loc Z, Image UUID, ForSaleStatus, Category,<br>ForSalePrice,<br>> AuctionID, Owner UUID, OwnerIsGroup Flag. Some of these fields won't be<br>
> implemented for a long time (especially ParentEstates) but it's good to<br>have<br>> those anyway.<br>><br>> The "Classifieds" search tab requires these fields: Entry UUID, Name,<br>> Description, Publisher UUID, Publisher Parent Estate ID, Image UUID,<br>
> ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X, Loc Y, Loc<br>Z,<br>> MatureFlag.<br>><br>> The "Events" calendar search tab requires these fields: Event UUID,<br>> Name, Description, Publisher UUID, Publisher Parent Estate ID, Mature<br>
> Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc Y, Loc Z,<br>> Cover Charge. The Event calendar also supports notifying people who<br>opt-in,<br>> so it would also require another table with Event UUID and Subscribing<br>
> Avatar UUID.<br>><br>> New Search (which I don't forsee being able to implement until way<br>> later) also requires sim object data. Object UUID, Parent Parcel UUID,<br>Name,<br>> ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good enough.<br>
><br>> Now I need your opinion on this schema. Is it a good idea to have each<br>> type of searchable object in a separate table? Or would it be more<br>feasible<br>> to have all the relevant fields in a single table "search" with an<br>
> "objecttype" enum to differentiate between the types?<br>><br>> From,<br>> KMeist Hax<br>><br>> ------------------------------<br>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it<br>
><br>now.<<a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ" target="_blank">http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i6<br>2sR8HDtDypao8Wcj9tAcJ</a>><br>
><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><a href="https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/4c13fe39/attachment-0001.html" target="_blank">https://lists.berlios.de/pipermail/opensim-dev/attachments/20080204/4c13fe39<br>
/attachment-0001.html</a><br><br>------------------------------<br><br>_______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br><br><br>End of Opensim-dev Digest, Vol 6, Issue 5<br>*****************************************<br>
<br>_______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote></div><br>