From: jon.stephens Date: March 4 2011 4:56pm Subject: svn commit - mysqldoc@oter02: r25265 - in trunk: refman-5.0 refman-5.1 refman-5.5 refman-5.6 refman-6.0 List-Archive: http://lists.mysql.com/commits/132497 Message-Id: <20110304165622.980B07805D@oter02.norway.sun.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Author: js221926 Date: 2011-03-04 17:56:22 +0100 (Fri, 04 Mar 2011) New Revision: 25265 Log: Fix typo Big nested important note -- De-gunk, make formalpara, add ID Add link in 5.1/Cluster version Modified: trunk/refman-5.0/se-memory.xml trunk/refman-5.1/mysql-cluster-overview.xml trunk/refman-5.1/se-memory-core.xml trunk/refman-5.5/se-memory-core.xml trunk/refman-5.6/se-memory-core.xml trunk/refman-6.0/se-memory-core.xml Modified: trunk/refman-5.0/se-memory.xml =================================================================== --- trunk/refman-5.0/se-memory.xml 2011-03-04 16:47:37 UTC (rev 25264) +++ trunk/refman-5.0/se-memory.xml 2011-03-04 16:56:22 UTC (rev 25265) Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 597 bytes @@ -34,7 +34,7 @@ - The MEMORY storage engine associate each table + The MEMORY storage engine associates each table with one disk file. The file name begins with the table name and has an extension of .frm to indicate that it stores the table definition. Modified: trunk/refman-5.1/mysql-cluster-overview.xml =================================================================== --- trunk/refman-5.1/mysql-cluster-overview.xml 2011-03-04 16:47:37 UTC (rev 25264) +++ trunk/refman-5.1/mysql-cluster-overview.xml 2011-03-04 16:56:22 UTC (rev 25265) Changed blocks: 1, Lines Added: 7, Lines Deleted: 0; 694 bytes @@ -4905,6 +4905,13 @@ + For information about the relative characteristics of the + NDB and + MEMORY storage engines, see + . + + + See , for additional information about MySQL storage engines. Modified: trunk/refman-5.1/se-memory-core.xml =================================================================== --- trunk/refman-5.1/se-memory-core.xml 2011-03-04 16:47:37 UTC (rev 25264) +++ trunk/refman-5.1/se-memory-core.xml 2011-03-04 16:56:22 UTC (rev 25265) Changed blocks: 2, Lines Added: 87, Lines Deleted: 85; 6643 bytes @@ -40,7 +40,10 @@ Features - + + + <literal>MEMORY</literal> compared with MySQL Cluster + Developers looking to deploy applications that use the MEMORY storage engine should consider @@ -49,107 +52,106 @@ characteristics: - + - - - Operations such as session management or caching - - + - - - In-memory storage for fast access and low latency - - + + + Operations such as session management or caching + + - - - A read-only or read-mostly data access pattern (limited - updates) - - + + + In-memory storage for fast access and low latency + + - + + + A read-only or read-mostly data access pattern (limited updates) + + - - However, MEMORY performance is - constrained by contention resulting from single-thread execution - and table lock overhead when processing updates. This limits - scalability when load increases, particularly for statement mixes - that include writes. Also, MEMORY - does not preserve table contents across server restarts. - + - - MySQL Cluster offers the same features as the - MEMORY engine with higher performance - levels, and provides additional features not available with - MEMORY: - + + However, MEMORY performance is + constrained by contention resulting from single-thread execution and + table lock overhead when processing updates. This limits scalability + when load increases, particularly for statement mixes that include + writes. Also, MEMORY does not preserve + table contents across server restarts. + - + + MySQL Cluster offers the same features as the + MEMORY engine with higher performance + levels, and provides additional features not available with + MEMORY: + - - - Row-level locking and multiple-thread operation for low - contention between clients - - + - - - Scalability even with statement mixes that include writes - - + + + Row-level locking and multiple-thread operation for low + contention between clients + + - - - Optional disk-backed operation for data durability - - + + + Scalability even with statement mixes that include writes + + - - - Shared-nothing architecture and multiple-host operation with - no single point of failure, enabling 99.999% availability - - + + + Optional disk-backed operation for data durability + + - - - Automatic data distribution across nodes; application - developers need not craft custom sharding or partitioning - solutions - - + + + Shared-nothing architecture and multiple-host operation with no + single point of failure, enabling 99.999% availability + + - - - Support for variable-length data types (including - BLOB and - TEXT) not supported by - MEMORY - - + + + Automatic data distribution across nodes; application developers + need not craft custom sharding or partitioning solutions + + - + + + Support for variable-length data types (including + BLOB and + TEXT) not supported by + MEMORY + + - - For a white paper with more detailed comparison of the - MEMORY storage engine and MySQL - Cluster, see - Scaling - Web Services with MySQL Cluster: An Alternative to the MySQL - Memory Storage Engine. This white paper includes a - performance study of the two technologies and a step-by-step guide - describing how existing MEMORY users - can migrate to MySQL Cluster. - - + - The MEMORY storage engine associate each table + For a white paper with more detailed comparison of the + MEMORY storage engine and MySQL + Cluster, see + Scaling + Web Services with MySQL Cluster: An Alternative to the MySQL Memory + Storage Engine. This white paper includes a performance + study of the two technologies and a step-by-step guide describing + how existing MEMORY users can migrate + to MySQL Cluster. + + + + The MEMORY storage engine associates each table with one disk file. The file name begins with the table name and has an extension of .frm to indicate that it stores the table definition. Modified: trunk/refman-5.5/se-memory-core.xml =================================================================== --- trunk/refman-5.5/se-memory-core.xml 2011-03-04 16:47:37 UTC (rev 25264) +++ trunk/refman-5.5/se-memory-core.xml 2011-03-04 16:56:22 UTC (rev 25265) Changed blocks: 2, Lines Added: 87, Lines Deleted: 85; 6643 bytes @@ -40,7 +40,10 @@ Features - + + + <literal>MEMORY</literal> compared with MySQL Cluster + Developers looking to deploy applications that use the MEMORY storage engine should consider @@ -49,107 +52,106 @@ characteristics: - + - - - Operations such as session management or caching - - + - - - In-memory storage for fast access and low latency - - + + + Operations such as session management or caching + + - - - A read-only or read-mostly data access pattern (limited - updates) - - + + + In-memory storage for fast access and low latency + + - + + + A read-only or read-mostly data access pattern (limited updates) + + - - However, MEMORY performance is - constrained by contention resulting from single-thread execution - and table lock overhead when processing updates. This limits - scalability when load increases, particularly for statement mixes - that include writes. Also, MEMORY - does not preserve table contents across server restarts. - + - - MySQL Cluster offers the same features as the - MEMORY engine with higher performance - levels, and provides additional features not available with - MEMORY: - + + However, MEMORY performance is + constrained by contention resulting from single-thread execution and + table lock overhead when processing updates. This limits scalability + when load increases, particularly for statement mixes that include + writes. Also, MEMORY does not preserve + table contents across server restarts. + - + + MySQL Cluster offers the same features as the + MEMORY engine with higher performance + levels, and provides additional features not available with + MEMORY: + - - - Row-level locking and multiple-thread operation for low - contention between clients - - + - - - Scalability even with statement mixes that include writes - - + + + Row-level locking and multiple-thread operation for low + contention between clients + + - - - Optional disk-backed operation for data durability - - + + + Scalability even with statement mixes that include writes + + - - - Shared-nothing architecture and multiple-host operation with - no single point of failure, enabling 99.999% availability - - + + + Optional disk-backed operation for data durability + + - - - Automatic data distribution across nodes; application - developers need not craft custom sharding or partitioning - solutions - - + + + Shared-nothing architecture and multiple-host operation with no + single point of failure, enabling 99.999% availability + + - - - Support for variable-length data types (including - BLOB and - TEXT) not supported by - MEMORY - - + + + Automatic data distribution across nodes; application developers + need not craft custom sharding or partitioning solutions + + - + + + Support for variable-length data types (including + BLOB and + TEXT) not supported by + MEMORY + + - - For a white paper with more detailed comparison of the - MEMORY storage engine and MySQL - Cluster, see - Scaling - Web Services with MySQL Cluster: An Alternative to the MySQL - Memory Storage Engine. This white paper includes a - performance study of the two technologies and a step-by-step guide - describing how existing MEMORY users - can migrate to MySQL Cluster. - - + - The MEMORY storage engine associate each table + For a white paper with more detailed comparison of the + MEMORY storage engine and MySQL + Cluster, see + Scaling + Web Services with MySQL Cluster: An Alternative to the MySQL Memory + Storage Engine. This white paper includes a performance + study of the two technologies and a step-by-step guide describing + how existing MEMORY users can migrate + to MySQL Cluster. + + + + The MEMORY storage engine associates each table with one disk file. The file name begins with the table name and has an extension of .frm to indicate that it stores the table definition. Modified: trunk/refman-5.6/se-memory-core.xml =================================================================== --- trunk/refman-5.6/se-memory-core.xml 2011-03-04 16:47:37 UTC (rev 25264) +++ trunk/refman-5.6/se-memory-core.xml 2011-03-04 16:56:22 UTC (rev 25265) Changed blocks: 2, Lines Added: 87, Lines Deleted: 85; 6643 bytes @@ -40,7 +40,10 @@ Features - + + + <literal>MEMORY</literal> compared with MySQL Cluster + Developers looking to deploy applications that use the MEMORY storage engine should consider @@ -49,107 +52,106 @@ characteristics: - + - - - Operations such as session management or caching - - + - - - In-memory storage for fast access and low latency - - + + + Operations such as session management or caching + + - - - A read-only or read-mostly data access pattern (limited - updates) - - + + + In-memory storage for fast access and low latency + + - + + + A read-only or read-mostly data access pattern (limited updates) + + - - However, MEMORY performance is - constrained by contention resulting from single-thread execution - and table lock overhead when processing updates. This limits - scalability when load increases, particularly for statement mixes - that include writes. Also, MEMORY - does not preserve table contents across server restarts. - + - - MySQL Cluster offers the same features as the - MEMORY engine with higher performance - levels, and provides additional features not available with - MEMORY: - + + However, MEMORY performance is + constrained by contention resulting from single-thread execution and + table lock overhead when processing updates. This limits scalability + when load increases, particularly for statement mixes that include + writes. Also, MEMORY does not preserve + table contents across server restarts. + - + + MySQL Cluster offers the same features as the + MEMORY engine with higher performance + levels, and provides additional features not available with + MEMORY: + - - - Row-level locking and multiple-thread operation for low - contention between clients - - + - - - Scalability even with statement mixes that include writes - - + + + Row-level locking and multiple-thread operation for low + contention between clients + + - - - Optional disk-backed operation for data durability - - + + + Scalability even with statement mixes that include writes + + - - - Shared-nothing architecture and multiple-host operation with - no single point of failure, enabling 99.999% availability - - + + + Optional disk-backed operation for data durability + + - - - Automatic data distribution across nodes; application - developers need not craft custom sharding or partitioning - solutions - - + + + Shared-nothing architecture and multiple-host operation with no + single point of failure, enabling 99.999% availability + + - - - Support for variable-length data types (including - BLOB and - TEXT) not supported by - MEMORY - - + + + Automatic data distribution across nodes; application developers + need not craft custom sharding or partitioning solutions + + - + + + Support for variable-length data types (including + BLOB and + TEXT) not supported by + MEMORY + + - - For a white paper with more detailed comparison of the - MEMORY storage engine and MySQL - Cluster, see - Scaling - Web Services with MySQL Cluster: An Alternative to the MySQL - Memory Storage Engine. This white paper includes a - performance study of the two technologies and a step-by-step guide - describing how existing MEMORY users - can migrate to MySQL Cluster. - - + - The MEMORY storage engine associate each table + For a white paper with more detailed comparison of the + MEMORY storage engine and MySQL + Cluster, see + Scaling + Web Services with MySQL Cluster: An Alternative to the MySQL Memory + Storage Engine. This white paper includes a performance + study of the two technologies and a step-by-step guide describing + how existing MEMORY users can migrate + to MySQL Cluster. + + + + The MEMORY storage engine associates each table with one disk file. The file name begins with the table name and has an extension of .frm to indicate that it stores the table definition. Modified: trunk/refman-6.0/se-memory-core.xml =================================================================== --- trunk/refman-6.0/se-memory-core.xml 2011-03-04 16:47:37 UTC (rev 25264) +++ trunk/refman-6.0/se-memory-core.xml 2011-03-04 16:56:22 UTC (rev 25265) Changed blocks: 2, Lines Added: 87, Lines Deleted: 85; 6643 bytes @@ -40,7 +40,10 @@ Features - + + + <literal>MEMORY</literal> compared with MySQL Cluster + Developers looking to deploy applications that use the MEMORY storage engine should consider @@ -49,107 +52,106 @@ characteristics: - + - - - Operations such as session management or caching - - + - - - In-memory storage for fast access and low latency - - + + + Operations such as session management or caching + + - - - A read-only or read-mostly data access pattern (limited - updates) - - + + + In-memory storage for fast access and low latency + + - + + + A read-only or read-mostly data access pattern (limited updates) + + - - However, MEMORY performance is - constrained by contention resulting from single-thread execution - and table lock overhead when processing updates. This limits - scalability when load increases, particularly for statement mixes - that include writes. Also, MEMORY - does not preserve table contents across server restarts. - + - - MySQL Cluster offers the same features as the - MEMORY engine with higher performance - levels, and provides additional features not available with - MEMORY: - + + However, MEMORY performance is + constrained by contention resulting from single-thread execution and + table lock overhead when processing updates. This limits scalability + when load increases, particularly for statement mixes that include + writes. Also, MEMORY does not preserve + table contents across server restarts. + - + + MySQL Cluster offers the same features as the + MEMORY engine with higher performance + levels, and provides additional features not available with + MEMORY: + - - - Row-level locking and multiple-thread operation for low - contention between clients - - + - - - Scalability even with statement mixes that include writes - - + + + Row-level locking and multiple-thread operation for low + contention between clients + + - - - Optional disk-backed operation for data durability - - + + + Scalability even with statement mixes that include writes + + - - - Shared-nothing architecture and multiple-host operation with - no single point of failure, enabling 99.999% availability - - + + + Optional disk-backed operation for data durability + + - - - Automatic data distribution across nodes; application - developers need not craft custom sharding or partitioning - solutions - - + + + Shared-nothing architecture and multiple-host operation with no + single point of failure, enabling 99.999% availability + + - - - Support for variable-length data types (including - BLOB and - TEXT) not supported by - MEMORY - - + + + Automatic data distribution across nodes; application developers + need not craft custom sharding or partitioning solutions + + - + + + Support for variable-length data types (including + BLOB and + TEXT) not supported by + MEMORY + + - - For a white paper with more detailed comparison of the - MEMORY storage engine and MySQL - Cluster, see - Scaling - Web Services with MySQL Cluster: An Alternative to the MySQL - Memory Storage Engine. This white paper includes a - performance study of the two technologies and a step-by-step guide - describing how existing MEMORY users - can migrate to MySQL Cluster. - - + - The MEMORY storage engine associate each table + For a white paper with more detailed comparison of the + MEMORY storage engine and MySQL + Cluster, see + Scaling + Web Services with MySQL Cluster: An Alternative to the MySQL Memory + Storage Engine. This white paper includes a performance + study of the two technologies and a step-by-step guide describing + how existing MEMORY users can migrate + to MySQL Cluster. + + + + The MEMORY storage engine associates each table with one disk file. The file name begins with the table name and has an extension of .frm to indicate that it stores the table definition.