Breaking the Scalability Barrier with Infinite Cache

Transcription

1 Breaking the Scalability Barrier with Infinite Cache An EnterpriseDB White Paper for DBAs, Application Developers, and Enterprise Architects September, 2009

2 Breaking the Scalability Barrier with Infinite Cache 2 Executive Summary Database systems are growing fast and exceeding expected volumes at an alarming rate. Web 2.0 applications, characterized by user community generated / accessed content are especially unpredictable when it comes to capacity planning. IT organizations are challenged to plan effectively for this explosive growth while adhering to shrinking or limited IT budgets. The cost of acquiring and maintaining bigger servers is forcing organizations to search for more affordable alternative solutions to growth. Traditional distributed cache solutions using commodity hardware clusters eventually degrade because of excessive cross server management of the cache. Infinite Cache from EnterpriseDB revolutionizes distributed cache management on commodity blade server hardware by substantially increasing the amount of memory available to hold data including entire databases with outstanding performance. Infinite Cache provides: massive scalability extremely high performance maintains data durability transparent access client applications An in depth discussion targeted specifically to your organization s scaling requirements can be scheduled with an EnterpriseDB domain expert by sending an to sales@enterprisedb.com.

3 Breaking the Scalability Barrier with Infinite Cache 3 Database Growth Traditional database systems characterized by data primarily generated internally or with partners, are growing fast and exceeding expected volumes at an alarming rate. In addition, the overwhelming success of many new social networking sites like Facebook, Twitter and hi5networks.com is adding a new explosive dimension to data volumes with huge user community generated content from blogs, wikis, forums, and media sharing. Hardware Solutions IT organizations are challenged to plan satisfactorily for this explosive and unpredictable growth while adhering to shrinking IT budgets. In some cases, if adequate capacity planning was done, a cost effective option is to upgrade the existing hardware, i.e. purchase more memory or if the server supports it, upgrade the CPU. This technique works for a while but eventually you reach the physical limits of the server. After exhausting options on existing hardware, the next option is to purchase a bigger and more powerful server which is fraught with migration and cost issues. Software Solutions So you start looking at what can be done at the software level to extend the life of the server. Projects to tune the software to make it run more efficiently are undertaken with mixed results. The reason for the mixed results is that the characteristics of the data and the application generally change over the application's lifetime. In addition, the amount of data causes traditional techniques to no longer produce significant results. Changes to the application are a possible solution but they require time and resources that may not be freely available. If you task developer resources to rework an older application, they are not available to work on new projects. Since it is no longer acceptable to simply go out and buy a larger server to run your database due to the cost associated with that class of server, and software solutions can produce mixed results, IT organizations must look for alternative solutions to the problem. Clustering Solutions

4 Breaking the Scalability Barrier with Infinite Cache 4 Then, database administrators and developers start looking at different types of database solutions to get the performance benefits necessary as well as allow for future growth. Some database vendors offer interesting scaling solutions that allow you to cluster multiple low-cost, commodity pieces of hardware together and thus increase the amount of memory and CPU available to process your business transactions. The problem with existing commercial solutions is that there is a penalty associated with the cross server management of the distributed caches. As more servers are added to the configuration, the management overhead incrementally degrades performance. In many cases the point of diminishing returns is reached all too quickly and merely postpones the day of scalability reckoning. Infinite Cache from EnterpriseDB EnterpriseDB recently introduced Infinite Cache, a distributed cache system that solves the problem of scaling your database with affordable commodity hardware and without the diminishing returns of traditional commodity server solutions. Infinite Cache is based on coupling low cost, commodity server blades to a main database server. An Infinite Cache setup allows database systems to access cache memory outside the physical database server s capacity by accessing memory caches on the blade servers. Infinite Cache can scale to many terabytes and beyond. Infinite Cache solves the scalability problem by breaking the limits of your commodity x86 hardware s memory capacity and avoiding the cost of purchasing a new, larger class of proprietary UNIX server to be your database server. The explosive (and expensive) growth management problem is solved by Infinite Cache s limitless expansion capability of adding affordable cache blades in step with demand. Infinite Cache allows you to hold data blocks in memory longer, ensuring high speed memory access to your data instead of paying the price of additional disk I/O which is slower. The amount of data blocks that can be held in memory is also substantially increased by enabling the use of compression, typically expanding the effective cache size by a factor of 3 or 4. The main database server and the cache blades are connected via highspeed, low-latency network connections such as InfiniBand. The system can have as many cache blades as necessary to try to maintain the 'read

5 Breaking the Scalability Barrier with Infinite Cache 5 mostly' portion of your data in memory. The more transactional data would reside in the main database server s buffer cache; ensuring transactions are performed at optimal speeds. Figure 1 illustrates the solution in more detail. Figure 1: Infinite Cache Architecture The EnterpriseDB Infinite Cache solution is comprised of the following components: Postgres Plus Advanced Server database Primary database server, e.g. 4 quad core CPUs, 64GB RAM Database storage (SAN, DAS, NFS) n Cache servers n CPUs, single core x GBs RAM InfiniBand or 10 Gigabit Ethernet High speed switch The diagram above shows Infinite Cache blade servers each with a single CPU socket with 128G of RAM. The number of CPUs and amount of RAM used is entirely up to the system architect. Relying on electromechanical hard disks data access is much slower than accessing data directly from memory. Infinite Cache allows you to substantially reduce the amount of random disk I/O and achieve greater database performance as a result. The configuration goal of Infinite Cache is to provide an enough memory to keep the relatively static portion of your database in cache thus providing rapid memory access instead of requiring disk I/O and swapping out other data from the database shared buffer cache. Infinite Cache s compression option provides added flexibility to maximizing the use of existing hardware. And you even have the flexibility to run your cache blades on different operating systems with Infinite Cache without any additional effort.

6 Breaking the Scalability Barrier with Infinite Cache 6 How Infinite Cache Works When a request comes into the database the first lookup is to see if the requested data is in the database shared buffers. If it is not in the shared buffers of the main database then it checks the Infinite Cache to see which cache nodes are holding the requested data and pulls the data blocks from the appropriate cache servers. Since the data is distributed across the cache servers using a hashing algorithm, the database engine uses the same algorithm to determine which node(s) it needs to contact to retrieve the data to satisfy the request. Optimizations have also been built in so the database can detect and determine if it would be faster to retrieve data directly from disk instead under certain circumstances. For instance, Advanced Server detects when disk required operations (such as index updates or sequential scans) are needed and avoids fetching data from Infinite Cache. To maintain data integrity, Advanced Server ensures the cache never gets stale by only sending modified data back to Infinite Cache. Data Compression Infinite Cache may also be configured to optionally use compression when storing the cached pages of data blocks. Data compression significantly increases the amount of data that can be cached in the existing memory configuration. The overhead associated with compressing and decompressing is relatively small compared to performing disk I/O. However, data variability can have a big impact on compression/decompression performance and actual storage savings achieved. To help DBAs achieve the optimal compression performance for their data, Infinite Cache contains 10 compression level values that can be changed while the server is running. The use of compression can increase the effective cache size by almost a factor of 5. For instance, an entire 250GB database can be completely cached in memory in a 2 node Infinite Cache configuration totaling 55GB of RAM. The fact that Infinite Cache can compress each page may make it attractive to configure a secondary cache server on the same computer that runs your Postgres server. If, for example, your computer is

7 Breaking the Scalability Barrier with Infinite Cache 7 configured with 6GB of RAM, you may want to allocate a smaller amount (say 1GB) for the primary cache (the shared buffer cache) and a larger amount (4GB) to the secondary cache (Infinite Cache), reserving 1GB for the operating system. Since the secondary cache resides on the same computer, there is very little overhead involved in moving data between the primary and secondary cache. All data stored in the Infinite Cache is compressed so the secondary cache can hold many more pages than would fit into the (uncompressed) shared buffer cache. If you had allocated 5GB to the shared buffer cache, the cache could hold no more than pages (approximately). By assigning 4GB of memory to Infinite Cache, the cache may be able to hold pages (at 2x compression), pages (at 3x compression) or more. The compression factor that you achieve is determined by the amount of redundancy in the data itself and the edb_icache_compression_level parameter. Cache Warming Infinite Cache provides a variety of flexible options for populating the cache. The cache can be warmed manually, automatically upon startup using simple scripts, warmed dynamically during application usage, warm entire tables or only portions of tables. Automatic or Manual Pre-Load If desired, Infinite Cache will automatically pre-load the cache servers on system startup. Assuming you have configured Infinite Cache with enough memory and/or use of the compression option, you could load your entire database into memory at startup. Even if your system is configured with less memory than the overall size of the database, Infinite Cache also provides the capability to target specific tables to be pre-loaded. This is particularly useful for lookup tables, reference data, or for specific large, frequently accessed tables that are relatively static since they will be held in memory until the system is shutdown. An automatic configuration parameter, edb_icache_warm_tables in the postgresql.conf file can be set to include a list of tables to warm at startup giving users instant high performance the first time they access the database application.

8 Breaking the Scalability Barrier with Infinite Cache 8 Pre-warming the cache is optional but highly recommended so users can get the benefits of Infinite Cache quickly. Tables can also be loaded into the cache manually during application uptime, using a function called edb_icache_warm that can be invoked by the database administrator using Postgres Studio or a command line utility. The DBA passes in a table name, executing a command like select edb_icache_warm('accounts'). It is called once for each target table to be cached, and it will load both table and index blocks for the specified table. While this is happening, the table in the database is still available to users for both querying and updating. This flexibility to warm tables in-flight allows DBAs to discover through actual usage, those tables in need of caching, and then cache those tables without interrupting service. Finally, it is also possible to load up just a subset of a table, to avoid doing extra work when very large tables will not fit completely in memory. This could be useful if there is one huge table and there is not enough cache available to store the whole table. For example, if a table is several times larger than the cache size, we don t want the cache warming function to spend time trying to load up the entire table, as it will just end up removing blocks from the cache that it just populated. Once the cache is fully populated, an LRU algorithm replaces older cache data with newly accessed data. The advantage of explicitly pre-loading the cache is that the data blocks are efficiently read in and put into the cache, saving even more time on subsequent random read access. Dynamic Cache Loading If you choose not to pre-load the cache, it will be populated dynamically during normal usage. This technique caches only the most frequently used data and is a more granular approach than caching entire tables. During normal usage, pages of data are read into the core buffer cache. Once it is full, older pages are evicted to make room for newer pages. In an Infinite Cache configuration, instead of discarding the old pages they are put into the Infinite Cache and thus remain in high speed memory. The result of this process is that the Infinite Cache is populated over time only with data blocks that had previously been requested. Note that any page evicted from the core buffer cache that has been modified is immediately written to disk and is also put into Infinite Cache to ready the latest data for a subsequent fetch. This dynamic cache loading technique has the advantage of only caching data that is actually requested. This can make more effective use of the

9 Breaking the Scalability Barrier with Infinite Cache 9 cache when you cannot accurately pre-determine what data needs to be pre-loaded and allows actual usage to dictate the contents of the cache. However if enough cache space is available pre-warming is recommended. Parallel Cache Warming To assist with warming large caches for very large databases, Infinite Cache also provides a command line binary utility that allows pre-loading specified tables. The utility also contains an option to run in multiple parallel processes significantly speeding up the warming process. For systems with multiple cores, it is recommended to run as many jobs as the number of cores, to utilize the maximum CPU cycles available and warm the cache in a minimal amount of time. Node Failure Handling If a cache server should fail unexpectedly, there are built in mechanisms to gracefully reinitialize and reuse the cache server once it becomes available again. If a cache server becomes unavailable for any reason, Infinite Cache will route the request for the data to the main database disk thus ensuring the data request is satisfied regardless of the cache server failure. During this time, the other cache servers will continue to be used normally, ensuring that high cache utilization rates continue. Postgres Plus Advanced Server will periodically check to see if the downed node is back up and accessible. If the node is functioning, Infinite Cache will try and avoid invalidating the entire node's cache if possible. If a small number of blocks have attempted to be accessed during the downtime, but were eventually accessed from disk and also modified, only those blocks are updated back to the returning node, and the other cached data remains accessible. This is particularly effective for handling brief intermittent network failures. If the node was down for a longer period of time with many blocks needing to be accessed from disk, the failed node's entire cache contents will be invalidated. In such cases, the node can be optionally re-warmed with a configurable list of tables. Infinite Cache Configuration and Execution Configuring and executing Postgres Plus Advanced Server with Infinite Cache is a straight-forward process.

10 Breaking the Scalability Barrier with Infinite Cache 10 On all of the Infinite Cache nodes, a daemon process called edb-icache is first started, specifying how much memory to allocate for the cache. On the database server, the postgresql.conf configuration file is modified. There are three parameters specific to Infinite Cache. The first, edb_enable_icache indicates whether or not the cache should be used, and is changed to ON. The second parameter, edb_icache_servers, specifies the list of servers hosting the Infinite Cache daemons. The value takes the form of a comma-separated list of hostname (or IP address):port entries. If the port number is not specified, the value defaults to An example setting appears below. edb_icache_servers = 'licache1, icache2:11000, ' The third parameter, edb_icache_compression_level specifies the compression level that should be used while storing the pages into Infinite Cache. The default value is 6. A value of 0 disables the compression and a value of 9 tries to provide the maximum compression. Note that compression will need some CPU cycles and hence using a mid-level of 6 can provide good compression without being too CPU intensive. On the database server, there is no extra process that needs to be started; Postgres Plus Advanced Server is started as normal, and it will try and use the caching nodes specified. If the database server cannot access any of the caching nodes for some reason, it will continue to execute, while periodically retrying to see if the node is back up and functioning so that it can begin utilizing it. Statistics and Monitoring Infinite Cache provides a flexible API (accessible from Postgres Studio or the command line SQL interface) that provides multiple statistics on Infinite Cache. One can view statistics for individual tables and indexes, or for the entire database. You can even interrogate Infinite Cache nodes directly to obtain their individual statistics. In addition to the API, more statistics can be obtained from some of the internal catalog views as well. A set returning function called edb_icache_tool() provides access to the state of individual Infinite Cache nodes along with their operating statistics. The list of available statistics includes:

11 Breaking the Scalability Barrier with Infinite Cache 11 hostname port status bytes_written cmd_get cmd_set connection_structures curr_connections curr_items evictions get_hits get_misses limit_maxbytes pid pointer_size rusage_user rusage_system threads total_time total_connections total_items uptime version Some usage examples appear below: SELECT * FROM edb_icache_stats(); Get all statistics for all Infinite Cache nodes. SELECT * FROM edb_icache_stats() WHERE hostname = server_name; SELECT hostname, port, status FROM edb_icache_stats(); Get statistics for just the specified node. Get the status of all defined Infinite Cache nodes. In addition to this function, statistics can be obtained from some of the internal catalog views. The view pg_stat_database has the added column blks_hit_icache. In addition, the columns heap_blks_hit_icache and idx_blks_hit_icache have been added to the following tables: pg_statio_all_tables pg_statio_sys_tables pg_statio_user_tables pg_statio_all_indexes pg_statio_sys_indexes pg_statio_user_indexes

12 Breaking the Scalability Barrier with Infinite Cache 12 The addition of these data columns allows administrators to report on the status and usage characteristics of their particular application. Performance Results Below are some sample test results that demonstrate the utility and capability of Infinite Cache. For all of these tests, the utility pgbench (an open source performance benchmarking tool included in Postgres Plus) was used for benchmarking performance. Localhost Infinite Cache Compressed For this test, no external cache nodes were used. The system was configured with just a single local compressed Infinite Cache setup. The test performed a SELECT only run (by using the -S option). Configuration: Quad Processor Quad Core 64 Bit Intel (16 cores total) 6 Drive (10,000 rpm) RAID 0 Array 8 GB RAM 2 GB shared_buffers (internal cache) 45 GB pgbench database 5 GB compressed local Infinite Cache Results: Advanced Server without local cache: 1,515 tps Compressed in local Infinite Cache (no other nodes): 8,363 tps The result is a five times (5X) improvement in SELECT statement throughput. 3-Node Networked Infinite Cache This test used a three cache node cluster connected over a network. The cache data was not compressed. The test performed a SELECT. Configuration: Main Database Server Quad Processor Quad Core 64 Bit Intel (16 cores total) 6 Drive (10,000 rpm) RAID 0 Array 8 GB RAM 2 GB shared_buffers (internal cache) 45 GB pgbench database

13 Breaking the Scalability Barrier with Infinite Cache 13 3 Infinite Cache Nodes Connected via InfiniBand Dual Core 64 Bit Intel Processor 16 GB RAM (15 GB configured for cache) Results: Advanced Server without local cache: 1,515 tps With Infinite Cache (no compression) on 3 nodes: 14,537 tps Again, the result is nearly a ten times (10X) improvement in SELECT statement throughput. 4-Node Networked Infinite Cache Compressed Including Updates In this test, the performance characteristics of using both compression and multiple nodes for different workloads were examined. Configuration: Main Database Server Quad Processor Quad Core 64 Bit Intel (16 cores total) 6 Drive (10,000 rpm) RAID 0 Array 8 GB RAM 2 GB shared_buffers (internal cache) 200 GB database 4 Infinite Cache Nodes Connected via InfiniBand Dual Core 64 Bit Intel Processor 8 GB RAM (7 GB configured for cache) Compression Enabled

14 Breaking the Scalability Barrier with Infinite Cache 14 Figure 2: Infinite Cache Performance In tests involving only SELECT statements, a more than 15 times improvement in statements per second handled can be seen. For workloads that involve UPDATE statements as well, Infinite Cache still yields significant benefits. For a workload that includes 10% of the activity being UPDATE statements, performance is 5.75 times faster, and with 25% UPDATE activity, performance is 3.46 times faster. For details of the tests environment and methods, please contact sales@enterprisedb.com. Application Transparency The last but not least feature to discuss about Infinite Cache is preparing applications to use it. This is where Infinite Cache really shines bright for application developers as it requires no special coding. In fact, to use Infinite Cache requires no additional coding at all. The Infinite Cache architecture is crafted in such a way that it is completely transparent to the client application. This is true for Read Only data warehousing type applications as well as mixed load applications that update data.

15 Breaking the Scalability Barrier with Infinite Cache 15 Updates to data are handled transparently with Infinite Cache s patent pending algorithms. All database transactions are respected. Blocks of changed data are updated to disk as well as Infinite Cache as they are ejected from the pg-buffercache via the normal LRU algorithms. This simple mechanism ensures high efficiency, transactional integrity, and complete transparency to the client application. Conclusion The increasing popularity and use of Web 2.0 architectures characterized by massive amount of user community generated data calls for a high performing, easily scaled, and cost effective database caching solution. Postgres Plus Advanced Server with Infinite Cache provides a powerful and flexible mechanism for scaling database performance by increasing cache memory beyond the physical limits of the core database server. Infinite Cache provides an easy and cost effective build out strategy for increasing database cache size through the addition of inexpensive commodity blade servers into the architecture. By leveraging Infinite Cache, performance gains of 3 to 15 times faster than existing configurations can be achieved. For more information regarding Infinite Cache in your environment, please contact us at: or contact the Sales department at: sales-us@enterprisedb.com (US), sales-intl@enterprisedb.com (Intl), or call , About EnterpriseDB EnterpriseDB is the leading provider of enterprise class products and services based on PostgreSQL, the world's most advanced open source database. The company's Postgres Plus products are ideally suited for transaction-intensive applications requiring superior performance, massive scalability, and compatibility with proprietary database products. Postgres Plus also provides an economical open source alternative or complement to proprietary databases without sacrificing features or quality. EnterpriseDB has offices in North America, Europe, and Asia. The company was founded in 2004 and is headquartered in Edison, N.J. For more information, please call or visit.