I have been learning / working on MSSQL (2005/2008) on
- Database Development
- High-availability (Replication / Log Shipping / Mirroring / Clustering)
- Performance Tuning (Index Tuning, Partitioning)
- Performance Testing (To validate Peak Load performance, Web Service response at peak loads)
Last night I attended Technical Overview Session on NuoDB. The Session was very impressive. Outcome of Session is ‘NuoDB has the potential to become dominant player in Cloud based Database Platform’. I have prepared a Table comparing NuoDB features against MSSQL.
| Feature | MSSQL | SQL Azure | NuoDB | Comments |
| Processing | Parse, Execute, Cache. Transaction manager is invisible to the enduser. Rows, Pages, Extents are basics on Data Storage. | Parse, Execute, Cache. Transaction manager is invisible to the enduser. Rows, Pages, Extents are basics on Data Storage. Maximum Size is 50GB Limit. | Transaction Manager and Archive manager are core components of the system. Everything in DB is an ATOM | |
| Database Scale out Architecture | Every Version has number of processors, RAM support. Based on the performance you can add /remove additional hardware physically | Not Mentioned. I am still checking MSDN | Add / Remove Transaction Manager, Archive Manager based on Need | Add / Remove Transaction and Archive Managers based on Need. During Holiday season scale out and in normal days reduce the AM/TM. NuoDB is scaleable. NuoDB Scales out immediately |
| Free Version | Express Edition free with 10GB data limit | 1 GB Trial Edition for 90 days | One Transaction manager and Archive manager Free | |
| Failover | Clustering, Mirroring, Logshipping | Replication, Mirroring – Not Supported | Multiple Archive Managers, Transaction Managers geographically distributed. All are peers. Data Distributed across all TM, DM | NuoDB is highly resilient, highly redundant. When there is no Archive Manager, Transaction Manager only then System will be down. This possibility requires lot of effort bring down all the data centres across the globe. Geo-Distribution (Active - Active Configuration). Database running in multiple places |
| Index Support | Clustered, Non-Clustered indexes | Clustered, Non-Clustered indexes | Supports B Tree based Indexes | |
| Stored Procedures | Supported | Supported | Supported | |
| Partitioning, Data Caching, Virtualization Support | Partitioning Supported, Caching - NA, Virtualization - Supported | Partitioning Not Supported, Caching - NA, Virtualization - Supported | Transaction manager has many characteristics of cache. Leverages deep knowledge of transaction. , Virtualization - Supported, Partitioning not supported | |
| Migrating from MSSQL | NA | NA | 90% SQL standards are applicable in NuoDB as well. There might be 10% additional work to be checked for migrating to NuoDB | |
| BI | PDW, SSIS, SSAS, SSRS | Currently no BI support in Version 1. NuoDB is best supported for Mixed workloads. Long running queries, Short running queries both work independently | ||
| Locking / Blocking, Versioning | Isolation levels defined. They define how locks are assigned. Version need to be enabled (RCSI) | Isolation levels defined. They define how locks are assigned. Version need to be enabled (RCSI) | MVCC based architecture for versions. Data is never deleted. | I am not too sure about this architecture for NuoDB. Need to check further |
I need to deep dive on specific aspects to write / expand further on above listed topics. To Summarize
- NuoDB is 100% ACID Compliant, Scaleable Database
- ACID compliance makes it Ahead of NOSQL DB
- NuoDB Scalability, High Availability Support makes it a potential dominant player for Cloud Database Platform
Happy Learning!!
2 comments:
Thanks Jim for correcting me. I need to learn on basics of NuoDB (MVCC, ATOM, ACID Handling).I have downloaded Whitepaper. I am going to try Beta version.
"MVCC doesn't mean that data is never deleted, just that old versions are kept for as long as a running transaction requires for consistency."
What abt a long SELECT working on a data that changed state from read>modified>commited all within the lifespan of the SELECT running from parallel session?
Post a Comment