Re: Sedna 3.0
Understood, one thing I'd like to see in the future is support for
collections that only accept documents that conform to a user defined XML
Schema.
Not only would this be beneficial in terms of developers using Sedna
knowing whether or not an XML document is valid by the Database
complaining when they tried to insert or update.
But surely this would also help with things like Sedna knowing how to
index the data easily, this surely would reduce the unpredictability
problem too?
Regards,
Charles
> Charles and Steve,
>
> having read this discussion I also have to agree with you that Sedna
> should
> share buffers between databases.
> We should think about it and include it in our to-do list.
>
> But please note that:
> 1) Memory consumption of XML databases will alsways be higher than in
> relational databases. In rdb everything is more or less predictable. If we
> read/modify an item (which is a tuple in rdb) we alway deal with only one
> page. If we read/modify an item in XML database it might occupy
> unpredictable number of pages. So to be efficient a database should have
> relatively large buffers (100 Mb or even more). So we are talking about
> sharing buffers, not reducing its size. Is it ok for your applications?
> 2) As ZNV mentioned it will be not easy to implement it in Sedna but we
> should do it.
>
> Maxim Grinev
> Sedna team
>
>
>
>
> 2008/3/31, Charles Foster <charles@...>:
>>
>> Hi,
>>
>> I have to agree with Steve about memory issues, I currently use 2
>> hosting
>> packages.
>>
>> 1 is a high cost dedicated root server, and can install anything I want.
>> 2 is a shared machine with my own Tomcat server, I am given 2 MySQL
>> Databases each running within the same server.
>>
>> I use Sedna on the dedicated root server, but am still not happy with
>> its
>> memory consumption.
>>
>> As far as a shared machine goes, installing and running Sedna is just
>> not
>> a option at the moment whether doing it myself or the host provider
>> themselves running 1 server with multiple databases. In this environment
>> I
>> am currently forced to use eXist instead.
>>
>> Regards,
>>
>>
>> Charles
>>
>>
>> > Hello ZVN,
>> >> Hello Steve,
>> >>
>> >> I believe we could fix the memory issue. This will require complex
>> >> redesign of Sedna. Basicly we have to change the responsibility and
>> >> communication of Sedna processes. Currently there exists a separate
>> >> process for each database running the separate instance of buffer
>> >> manager. This leads to 100MB (when default configuration is in
>> effect)
>> >> RAM used per DB - no matter how high the actual load is.
>> >>
>> >> We could rearrange things and merge all SM-s into a single process.
>> >> This is a lot of work. I am willing to make this changes - along with
>> >> other enhancements to the buffer manager and overal cleanup of Sedna
>> >> system design. However I need a solid reasoning to convince the team
>> >> to invest effort in this project. Any ideas?
>> > I think I do: without that kind of management, we won't ever see Sedna
>> > deployed in the wild. If you have a shared server, for instance, you
>> can
>> > safely deploy PostgreSQL or MySQL because they can manage hundreds of
>> > databases at once, using the memory you reserve for them. Sedna
>> however
>> > will
>> > choke the server's memory with only a few databases. That means
>> expensive
>> > (dedicated) hardware will have to be used for running Sedna.
>> >
>> > I have developed a web framework in Python which uses Sedna and lxml
>> [1]
>> > but I
>> > can't see it deployed on actual hosting providers because of the high
>> > Sedna
>> > memory requirements. Most VPS plans start with 64 or 128Mb of ram, for
>> > instance.
>> >
>> > Besides, it's a question of efficiency. Why wasting more memory then
>> > needed ?
>> >
>> > I'd however keep each database connection running in a separate
>> process
>> > and
>> > use a send process that would be the inter-process shared buffers
>> manager.
>> > This is the approach PostgreSQL uses, and will avoid a crashed
>> connection
>> > to
>> > shut down all the other connections or the whole database system. A
>> > similar
>> > implementation could be done in a single process using a buffers
>> manager
>> > and
>> > threaded connections, however that could be a bit harder to implement
>> due
>> > to
>> > threads compatibility issues among different operating systems.
>> >
>> > --
>> > Best Regards,
>> > Steve Howe
>> >
>> > [1] http://codespeak.net/lxml/
>> >
>>
>> >
>> -------------------------------------------------------------------------
>> > Check out the new SourceForge.net Marketplace.
>> > It's the best place to buy or sell services for
>> > just about anything Open Source.
>> >
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> > _______________________________________________
>> > Sedna-discussion mailing list
>> > Sedna-discussion@...
>> > https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>> >
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>>
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Sedna-discussion mailing list
>> Sedna-discussion@...
>> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>>
>
RSS Feed