|
BTree FAQ
This is the main source for existing knowledge about Btrees in general and Virtual Machinery's BTree implementation in particular. If you are an existing BTree Customer (or just have an interest in seeing how to code using Virtual Machinery's BTree) the you should go here to our BTree Tips and Tricks page.
What is the difference between a BTree and a database?
A Btree is a kind of database, in fact under the covers most database implementations use Btrees for the storage of their data. A Btree is rather like a persistent Hashmap. Virtual Machinery's BTree implementation allows you to store data at an indexed location in the same way that a Hashmap does. So in a Hashmap you can do -
Hashmap myHashmap = new Hashmap();
myHashmap.put("MyIndex", "MyData");
System.out.println(myHashmap.get("MyIndex");
|
and you would expect to see - MyData displayed on the console. Doing the same thing using a BTree you would write something like -
BTreeInterface myTree = BTree.createNewTree("TESTING");
myTree.put("MyIndex", "MyData");
System.out.println(myHashmap.get("MyIndex");
|
When and why should I use a BTree rather a database?
The factors that would guide you towards using a Btree rather than a database would be -
- You need very high performance
- You have a moderately sized set of data - somewhere between 10Mb and 4Gb (4Gb is the limit for a single Virtual Machinery BTree - but you can use more than one BTree)
- Your data has quite a simple structure - not a lot indices required, no need for complex queries or views
- You are looking for a low management overhead - no need for DB admins etc
- You need a small footprint solution (both code and data storage overhead - databases have a storage overhead for indices etc)
With BTrees and databases its very much horses for courses. Nowadays people start with a database in mind for their solution. Databases are cheap, reliable data storage mechanisms but sometimes they provide more functionality than we really need and we pay for that in performance and management costs. For very small changes to your design you can often gain huge benefits from choosing a BTree as your solution. We show one example here which is worth reading - almost all J2EE Server applications have a data set like the one in the example that could benefit from that approach. This page also includes a comparison table of BTrees vs other data storage solutions.
Why should I use Virtual Machinery's BTree implementation?
- It is extremely reliable and thoroughly tested having been on the commercial market place for nearly 20 years (the first version was written in Smalltalk)
- Very high performance
- Highly efficient and easily controllable caching
- Simple API
- Transaction control - commit and rollback
- Very small footprint and low data storage overhead
- Management toolkit available (you can purchase licenses to incorporate this into your own code)
- Source code options
You can find out more reasons in our BTree Guide here.
I want to develop a commercial application but don't want to buy a commercial license upfront - can you help me?
Of course we can. Virtual Machinery operate an additive license program - this means you only need to buy the license you need when you need it. You don't lose your initial investment either as each license builds on the one before. For example you might buy a base license to write your application. When you've completed your application you can then purchase a commercial distribution license which provides you with the code that you need to distribute with your application. Sometimes that's as far as you need to go - but , for example, you might want to purchase the source code to allow you to modify some feature of the BTree to fit better with your own code or you might choose to incorporate some features from the toolkit.
What is your upgrade policy?
Virtual Machinery's BTree implementation is a very stable product so usually any updates to the product are the result of providing support for other platforms. If we release a major release of the product within 60 days of your purchase you will receive that major release. We well send out minor releases and fixes to customers of a product release for a year after purchase. If you have purchased a commercial, Site or Corporate license and wish to updgrade to the latest version then you only need to purchase a new Base license and we will upgrade your license to the latest level.
Why can your BTree only hold 4GB of data?
This is simply a result of the way that we have coded it. At the time when we designed our BTree 4GB was an enormous amount of data. In fact the restriction is a maximum of 65533 data pages containing at most 65024 bytes of data which is a grand total of 4261217792 bytes or 3.97Gb. The size restriction allows us to code the BTree very effeiciently and it is one of the reasons for the very high performance of our BTree. The restriction applies to each BTree and as you may may use as many Btrees in your dataset as you like then its not really that much of a constriction when you come to think about it. You can find out how to use multiple Btrees to meet your data requirements on our Tips and Tricks page. We keep this situation under review but we have had very little pressure from customers to change the product. You can of course purchase the source code and customise the BTree to fit your exact needs.
Why is the maximum size of a piece of data 65024 bytes?
This is, (as in the case of 'Why can your BTree only hold 4GB of data?'), simply a coding restriction which allows to enhance the performance of our BTree. There are a number of ways to get around this restriction - see the section 'I want to store data that is bigger than the maximum 64k page size how do I do this with Virtual Machinery's BTree?' in our Tips and Tricks page. We keep this limitation under review and of course you can buy the source code and modify it to meet your needs
How do I close a Btree so that all my changes will be persisted?
This sometimes causes confusion because the action that you should take will depend on your previous actions. If you have just been using the BTree in 'normal' mode i.e. not using transactions then calling myTree.closeBTree() will be sufficient. If you have been using transactions you must call either commit() (if you want to keep your changes) or rollback() (if you want to discard the changes) before calling closeBTree(). There is one more action that you might choose to call - flush() - this writes any unwritten changes in the index and data page caches and writes out data related to the management of the BTree. An example of when you might call this would be during a large batch job where you want to be in a position to recover your data in event of a crash - typically you would be doing this under transaction control so you would call commit() then flush() every so many records. closeBTree() calls flush prior to closing the actual files in the dataset.
How does Virtual Machinery's Btree implementation deal with fragmentation?
Fragmentation is where the size of the file remains the same but the amount of data in it is reducing - this in effect ,means that you are wasting space. One of the compromises that we made on performance was to deal with this issue as it is particularly important for applications running on small capacity devices e.g. mobile phones, embedded devices. Virtual Machinery's BTree constantly seeks to merge the pages in the dataset and free unused space for reuse rather than taking more disk space. We also provide tools in the toolkit that will allow you to compress data sets to their optimum size - particularly useful if you are releasing prebuilt read only datasets with your application. If you purchase a toolkit source code license you can include these utilities in your application.
|
