faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: reiser4?
by Aaron J. Seigo on Wednesday 23/Feb/2005, @13:24
|
> but would it make sense to create a reiser4 plugin to be used with your ideas
seeing as our time is not exactly limitless, i don't think doing two implementations with different storage designs is realistic, especially when very, very few people have the target data storage mechanism (reiser 4 file system) available to them. this is meant to be a practical project rather than a research topic.
> One could argue that this is where the information belongs: in the filesystem
yes, that's a viable argument given that the information you are indexing/linking exists in the filesystem in the first place. this assumption isn't universally true, however. not only is a lot of our data dynamically generated on demand these days, there's also a lot of data that is implied by our usage forming context that isn't a "document" or even necessarily very suitable for storage as a "file" on disk.
trivial example: how would you store a personal annotation of a web page in a filesystem based approach?
if we wish to more than just index and search local data, it becomes apparent that the file system is not the catch-all locus of our information anymore. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: reiser4?
by me on Wednesday 23/Feb/2005, @14:04
|
well, I'd probably store all annotations in C:\Progra~1\Common~1\Annota~1\HSDS6SB.TMP\ddf7d6s7.txt
I guess you're right :)
|
[
Reply To This | View ]
|
|
|
Re: reiser4?
by Simon Edwards on Wednesday 23/Feb/2005, @14:15
|
> trivial example: how would you store a personal annotation of a web
> page in a filesystem based approach?
The direction that Reiser is heading is towards a general filesystem/retrival system. Kind of a mix of a traditional filesystem plus a database, while being very flexible and 'plastic' (i.e. you wouldn't have to define a fixed schema before you could use it). Searching using partial chunks of info being a big part it. Basically you could build and search almost arbitrary data-structures (on disk). A traditional Unix style filesystem is just one thing that you could make using this kind of system, but much more would be possible.
Read, (and try to get your head around, it's hard!), the Future Vision paper at:
http://www.namesys.com/
--
Simon
|
[
Reply To This | View ]
|
Re: reiser4?
by Aaron J. Seigo on Wednesday 23/Feb/2005, @15:35
|
> The direction that Reiser is heading is towards a general
> filesystem/retrival system
yes, it's a very interesting and ambitious goal, one Oracle failed at in the 90s, though for market reasons rather than technical ones.
> Basically you could build and search almost arbitrary
> data-structures (on disk)
of course, and we're using an RDBMS to do exactly that at the moment. the reason that a file system doesn't offer anything (featurewise) above what the RDBMS does to make it more attractive is that not everything in the necessary "arbitrary data structures" refer/link to things that are local or even storable (e.g. time).
it's much more practical and reasonable to require people to installed 10MB of software that provides a database engine than it is to require them to reformat their disks and migrate all their data over. Reiser isn't even available for all the platforms KDE runs on. this removes it as a potential target for a practical tool, though it would make a really cool target for a research project.
i do think that applications will drive the success of Reiser4, however. and once we have tools such as what we are building, i wouldn't be surprised if someone worked the storage layer to oprtionally use Reiser4 to produce something smaller and more performant. at that point there's a real motivator to use these kinds of file systems that goes beyond the theoretical, at which point they become interesting from the point of view of "off the shelf" software users and manufacturers.
> Read, (and try to get your head around, it's hard!),
> the Future Vision paper at:
i have =) fun stuff... i've been watching Reiser's project for some years now with great interest.
|
[
Reply To This | View ]
|
|
Re: reiser4?
by David Neeley on Saturday 28/Oct/2006, @14:00
|
Frankly, I believe that SQL databases in general may not be the best solution for this problem.
Some years ago, I was one of the investigators into a potential application in which we benchmarked various database solutions. The "post-relational" databases of which the old Pick system was progenitor had performance many times that of the relational ones.
In case you are unaware of it, these databases comply with all but one of the Codd and Date's Rules of Normalization--the first, that every item must be "unique and atomic." In other words, a single record could store an entire table.
Consider the common introduction to relational databases in which a video rental store is used. One table contains the individual customer records, with a unique customer number. Another table contains the rental records, with one column containing the customer ID numbers. To get a look at rental history for a given customer, then, a join must be performed in which the rental table is searched with each rental by the given customer's ID being extracted to build the list.
In a Pick-style database, the individual rental info can be stored directly int he customer table. Extracting rental info merely means looking up that customer record and viewing the ever-expanding rental list. No joins, far less memory, and much more speed!
Another possibility might be a datastore similar to the "Titanium" database of Micro Data Base Systems. In that one, many-to-many relations can be directly mapped as selected by the programmer. This results in a well-written program having even more performance yet.
In our tests, the Pick style database ran about 25 times faster than the then-current SQL databases; the Titanium engine about 40 times faster and with much lower system overhead.
In short, the only advantage I see for an SQL system is the large number of tools available for them.
David
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
