What's the FASTEST file storage option ?

Question

Hi all,
Im building an application in Java where indexing and storing of data is a major area of the app. It should be able to store the data as well as retrieve them rapidly as well as the files should be small in size.
Knowing Java's popularity with XML, I've chosen that as one candidate, but the problem is Im not too sure how the above 2 criteria will match with XML.
1) Is XML fast enuf considering retrieval of data ?
2) And how about the[b] storage sizes ?
Or should I scrap XML and build my own version file structure such as a B-tree ?
How difficult would that be considering limited development time ?
thanx in advance ....

Answer 1

Anyway to deal with this post piece by piece.
I agree with you that database infact rules out other
options when it comes to speed and storage. Im not in
anyway trying to abuse XML as a storage mechanism. If
I had the freedom to use a database, I know I wudnt
even hav posted this question, cos database wins
hands down in ease of programmin, maintain, store and
rapid response.
Okay first of all my post was not a personal attack against you. There are plenty of people who abuse or ty to abuse XML as a storage mechanism with extremely unhappy results. I want to make that point clear not just to you but to any future readers of this thread so that if they are considering such a course of action they should come back to reality.
It wud be insane to ask the client to
to install a DBMS jus to make sure the P2P app wud
run. As for the details about the solution, it is a
P2P app, but not to share content as such traditional
ones. Its supposed to help ppl arrive at better
seacrh results on a Web Search Engine.Well this was dealt with previously. In short using JDBC does NOT imply a full blown database server. It could be a standalone database like Access or you could write your own driver that accesses a proprietary file directly or you could use a plain text driver.
The point is that if you use JDBC you decouple your application from the storage. This is the important point. Because it means you can switch the storage mechanism as best fits you later without having to rewrite gobs of code.
>
As for the requiremtns, I need a storage mechanism
sm to store the rankings a user might have given
indivuidually per page or website. I need to store
them as well as access them anytime I want and share
them with the peers. Not only rankings I need to
store other deatils like the search string, the
datetime of the query etc.All the more reason to look at a database of some sort... an embedded database would be fine.
>
I will let you know more of the requiremtns as soon
on as I advance onto it. Right now Im not
concentratin on the storage part of it. ( Jus
thinking of goin ahead with XML ) and rather
implementing the P2P communication area. I was jus
doing some research on what would be the best storage
option for dealing with the app's "data". I read
on a book that B-Tress and such data structures can
actually be implemented on file storage thus giving
better performance. And also I was looking for
material ( white papers and such ) discussing the
various issues of each storage option available
currently which will stand as proof for the final
solution I am gonna take.
Okay here is the problem with all this. How do you think databases implement indexes?
Hint: while it is all in the end vednor specific the answer is some sort of tree structure.
So again back to the point if you want to write your own tree structure go right ahead... I think it's pointless but go right ahead. What you should do though is write it so that your application accesses this structure through JDBC so that later when you decide that re-inventing the wheel was not such a hot idea you can change the storage implementation without destroying your application.