Đang chuẩn bị liên kết để tải về tài liệu:
Introduction to the Zope Object Database

Greenplum’s SG Streaming™ technology ensures parallelism by “scattering” data from all source systems across hundreds or thousands of parallel streams that simultaneously flow to all Greenplum Database nodes (Figure 11). Performance scales with the number of Greenplum Database nodes, and the technology supports both large batch and continuous near-real-time loading patterns with negligible impact on concurrent database operations. Data can be transformed and processed in-flight, utilizing all nodes of the database in parallel, for extremely high-performance ELT (extract-load- transform) and ETLT (extract-transform-load-transform) loading pipelines. Final “gathering” and storage of data to disk takes place on all nodes simultaneously, with data. | Introduction to the Zope Object Database Jim Fulton Digital Creations jim@digicool.com Abstract The Zope Object Database provides an object-oriented database for Python that provides a high-degree of transparency. Applications can take advantage of object database features with few if any changes to application logic. Usage of the database is described and illustrated with an example. Features such as a plug-able storage interface rich transaction support undo and a powerful object cache are described. 1. Introduction Many applications need to store data for use over multiple application executions or to use more data than can practically be stored in memory. A number of approaches can be used to manage large amounts of persistent data. Perhaps the most common approach is to use relational database systems. Relational database systems provide a simple model for organizing data into tables and most can handle large amounts of data effectively. Because of their simple data model relational databases are easy to understand at least for small problems. Unfortunately relational databases can become quite cumbersome when the problem domain does not fit a simple tabular organization. An advantage of relational database systems is their programming-language neutrality. Data are stored in tables which are language independent. An application must read data from tables into program variables before use and must write modified data back to tables when necessary. This puts a significant burden on the application developer. A significant amount of application logic is devoted to translation of data to and from the relational model. An alternative is to retain the tabular structure in the program. For example rather than populating objects from tables simply create and use table objects within the application. In this case high-level tools can be used to load tables from the relational database. With sufficient knowledge of database keys tools could automate saving data when .