Sorry for the second email - also forgot to mention that we have very few number of users right now (internal company wiki) and that we had a major problem with sub-properties slowing everything down to unusable states, but not the time to figure out why (something like having 3+ sub properties broke everything).
I would like to also voice my support of Jeroen's requests -- these features are indeed essential to geographic queries (being able to sort by distance). I believe it is possible to do in the same manner in which 'where' statements are able to be modified by extensions (I have written up a beta expansion of SM and SMW to do this a few months ago - not using the built in GIS mysql features however but the haversine formula).
Right now I have an unadulterated SMW installation with about ~30million pages, ~23million of them have geographic coordinates. Distance queries take about ~240 seconds across them if loaded for the first time (lots of time building temp tables). Running Dual i7, 12gb ram - 8gb innodb buffer, 4x 7200 1tb drives in raid 10.
We are beginning to look into external stores - but with so much data and other work the testing and transfer would take some time.
We've also had to remove Semantic Drilldown and turn off auto-completion in Semantic Forms (be careful of Type:Page, automatically uses auto-completion).
p.s. Apologies for the really really bad distance query in the original SMW, was my first time working with SMW, and was impossible to do bounding-box with lat/lon being stored in the same field in MySQL ;)
On Wed, Feb 23, 2011 at 2:09 PM, Jeroen De Dauw <email@example.com> wrote:
Since this discussion is about performance and changes to the SMW storage layer, I'd like to bring up an issue I've been having as Semantic Maps dev.
To efficiently do spatial operations on geographical data stored by SMW, support for spatial extensions in MySQL and PostGis in PostGres is needed. Currently there is no way to make use of these database extensions, as the SMW storage layer does not allow for:
* specifying what type of index to place on a field (it only allows specifying a field should be indexed)
* putting SQL functions in insert and select statements (which is needed to insert or select geographical entities)
I'm not sure to what extend supporting this is possible, but it would make a huge difference for working with geographical data in SMW. So I'd be nice if this was kept into consideration when modifications to the storage layer are made.
In any case, the current distance query in Semantic Maps already performs way better then the one in older versions of SMW (which was really really ... really bad). More incentive for Wikia to update :)
Jeroen De Dauw
Don't panic. Don't be evil.
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
Semediawiki-devel mailing list