Archive for December, 2012
It is all well and good to wave one’s hands and say “InnoDB clearly requires far more memory for these reasons,” but it gets slightly difficult to pin down exactly how much more memory. This is true for several reasons:
1. How did you load your database?
InnoDB table size is not a constant. If you took a straight SQL dump from a MyISAM table and inserted it into an InnoDB table, it is likely larger than it really needs to be. This is because the data was loaded out of primary key order and the index isn’t tightly packed because of that. If you took the dump with the order by primary argument to mysql dump, you likely have a much smaller table and will need less memory to buffer it.
2. What exactly is your table size?
This is an easy question to answer with MyISAM: that information is directly in the output of “SHOW TABLE STATUS”. However, the numbers from that same source for InnoDB are known to be estimates only. The sizes shown are the physical sizes reserved for the tables and have nothing to do with the actual data size at that point. Even the row count is a best guess.
3. How large is your primary key?
It was mentioned above that InnoDB clusters the data for a table around the primary key. This means that any secondary index leaves must contain the primary key of the data they “point to.” Thus, if you have tables with a large primary key, you will need more
memory to buffer a secondary index and more disk space to hold them. This is one of the reasons some people argue for short “artificial” primary keys for InnoDB tables when there isn’t one “natural” primary key.
There is no set method that will work for everyone to predict the needed resources. Worse than that, your needed resources will change with time as more inserts to your table increase its size and fragment the packing of the BTree. It is important to not run at 100% usage of the innodb buffer, as this likely means that you’re not buffering as much as you could for reads, and that you’re starving your write buffer which also lives in the same global innodb_buffer.
Crystal Reports Server is services-oriented architecture of BusinessObjects Enterprise. BusinessObjects Enterprise is a complete business intelligence (BI) platform that provides specialized end-user tools including Crystal Reports, Web Intelligence, OLAP Intelligence, Performance Manager, and Dashboard Manager. BusinessObjects Enterprise also includes data integration capabilities from Data Integrator. It is architected using modern web standards with an industry-standard communication framework to tie all the components and services together.
Crystal Reports Server harnesses the reporting services and components of the BusinessObjects Enterprise architecture to offer small and medium businesses a proven reporting solution. It addresses the complete reporting process—from data access and report design, to report management and delivery, to report integration with portals and enterprise applications.
Functional Architecture of Crystal Reports Server
Crystal Reports Server is comprised of separate—yet interconnected—components and services optimized for specific tasks. These components and services include:
- Data services for comprehensive and flexible data access
- Creation tool for flexible data formatting using Crystal Reports
- Platform services for report publishing, security, and processing
- Management tools for managing Crystal Reports Server services and objects
- Web and application services for customized report integration with portals and applications
- User interaction tier for end-user report viewing and interaction