On 09/10/12 18:12, Yaron Koren wrote:
> Hi,
>
> Nischay - thanks for that set of links. I don't think any of them cover
> the thinking behind the design decisions, but they're still all good to
> know about.
>
> Markus - thanks for all the clarifications. I was sure that the extra
> tables were done to improve reading, but it sounds like they're mostly
> there to improve writing.
I would not say that either of these is more important. Reading and
writing are both relevant, and the new design should improve both
activities in various situations.
> Is improving write performance a big deal,
> though? I'm no performance expert, but I would think that on an average
> wiki, writes are a fairly unimportant factor in the overall performance
> of the site. Is that incorrect?
Current versions of SMW can cause a very high write load (writing on
every edit, even if no data changed). This was an issue for Wikia and
for anyone who is running MW on SSD drives. Just checking if some data
has changed is not a solution, since the modification date always
changes. Having more tables allows for a more fine-grained write control.
>
> I didn't mean that the number of tables (around 30 in SMWSQLStore3) will
> pose a technical challenge, just that it looks cluttered - and may pose
> challenges for administrators, and developers, in maintaining them.
Not sure what kind of administration could be necessary. In general,
users and administrators should not touch the tables.
>
> I'm still thinking about MediaWiki's page_props table - both as a design
> example, and as a tool that SMW and related extensions can use. As a
> design example: MediaWiki stores many different types of values in the
> page_props table. Table writes (and reads) could probably be a little
> faster if there were separate tables for different types of page
> properties, but the MediaWiki developers decided to just have one big
> table for everything.
>
> And as a tool, page_props could potentially be helpful for SMW, SF and
> others. SF's special properties, like "Has default form", don't need to
> be queried alongside real semantic properties - and actually, I doubt
> they're queried often at all, other than by SF itself. SF's information
> could be stored in the page_props table, instead of via SMW - and then,
> instead of an SMW tag, you could just add something like this to a
> category, property or template page:
>
> {{#default_form:City}}
>
> If it reduces clutter, administrator confusion, and compatibility
> issues, without increasing read or write times, it might be worth it...
I don't see what you mean with clutter and administrator confusion. I
have never known how many tables MW uses internally, nor have the tables
in MW confused me so far. We never had compatibility issues between SF
and SMW so far either.
But pageprops could still be a good idea for SF. It should definitely
improve read performance. You can also store the data redundantly in SMW
and in PageProps, so you get the best of both (fast access, #ask,
Special:Browse, data export). If you do this, we would probably make the
SF properties less special in our code, since they would not be needed
so heavily.
Markus
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
