Author: paul
Date: 2010-07-14 21:00:24 +0200 (Wed, 14 Jul 2010)
New Revision: 21731
Log:
r61185@frost: paul | 2010-07-14 14:00:13 -0500
Add short comparison between MEMORY/Cluster
Modified:
trunk/refman-5.1/se-memory-core.xml
trunk/refman-5.5/se-memory-core.xml
trunk/refman-6.0/se-memory-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:40851
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:61181
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
+ 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:40851
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:61185
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
Modified: trunk/refman-5.1/se-memory-core.xml
===================================================================
--- trunk/refman-5.1/se-memory-core.xml 2010-07-14 18:44:10 UTC (rev 21730)
+++ trunk/refman-5.1/se-memory-core.xml 2010-07-14 19:00:24 UTC (rev 21731)
Changed blocks: 1, Lines Added: 104, Lines Deleted: 0; 3423 bytes
@@ -40,6 +40,110 @@
Features</citetitle>
</para>
+ <important>
+ <para>
+ Developers looking to deploy applications that use the
+ <literal role="se">MEMORY</literal> storage engine should consider
+ whether MySQL Cluster is a better choice. A typical use case for
+ the <literal role="se">MEMORY</literal> engine involves these
+ characteristics:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Operations such as session management or caching
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In-memory storage for fast access and low latency
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A read-only or read-mostly data access pattern (limited
+ updates)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ However, <literal role="se">MEMORY</literal> performance is
+ constrained by contention resulting from single-thread execution
+ and table lock overhead when processing updates. This limits
+ scalability when load increases.
+ </para>
+
+ <para>
+ MySQL Cluster offers the same features as the
+ <literal role="se">MEMORY</literal> engine with higher performance
+ levels, and provides additional features not available with
+ <literal role="se">MEMORY</literal>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Row-level locking and multiple-thread operation for low
+ contention between clients
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Scalability even with access mixes that include updates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Optional disk-backed operation for data durability
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Shared-nothing architecture and multiple-host operation with
+ no single point of failure, enabling 99.999% availability
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Automatic data distribution across nodes; application
+ developers need not craft custom sharding or partitioning
+ solutions
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Support for variable-length data types (including
+ <literal role="type">BLOB</literal> and
+ <literal role="type">TEXT</literal>) not supported by
+ <literal role="se">MEMORY</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For a white paper with more detailed comparison of
+ <literal role="se">MEMORY</literal> with MySQL Cluster and a guide
+ for migrating from <literal role="se">MEMORY</literal> to Cluster,
+ see
+ <ulink url="http://www.mysql.com/why-mysql/white-papers/mysql-wp_cluster-7.0_Cluster_MEMORY.php">Scaling
+ Web Services with MySQL Cluster: An Alternative to the MySQL
+ Memory Storage Engine</ulink>.
+ </para>
+ </important>
+
<para>
Each <literal>MEMORY</literal> table is associated with one disk
file. The file name begins with the table name and has an extension
Modified: trunk/refman-5.5/se-memory-core.xml
===================================================================
--- trunk/refman-5.5/se-memory-core.xml 2010-07-14 18:44:10 UTC (rev 21730)
+++ trunk/refman-5.5/se-memory-core.xml 2010-07-14 19:00:24 UTC (rev 21731)
Changed blocks: 1, Lines Added: 104, Lines Deleted: 0; 3423 bytes
@@ -40,6 +40,110 @@
Features</citetitle>
</para>
+ <important>
+ <para>
+ Developers looking to deploy applications that use the
+ <literal role="se">MEMORY</literal> storage engine should consider
+ whether MySQL Cluster is a better choice. A typical use case for
+ the <literal role="se">MEMORY</literal> engine involves these
+ characteristics:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Operations such as session management or caching
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In-memory storage for fast access and low latency
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A read-only or read-mostly data access pattern (limited
+ updates)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ However, <literal role="se">MEMORY</literal> performance is
+ constrained by contention resulting from single-thread execution
+ and table lock overhead when processing updates. This limits
+ scalability when load increases.
+ </para>
+
+ <para>
+ MySQL Cluster offers the same features as the
+ <literal role="se">MEMORY</literal> engine with higher performance
+ levels, and provides additional features not available with
+ <literal role="se">MEMORY</literal>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Row-level locking and multiple-thread operation for low
+ contention between clients
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Scalability even with access mixes that include updates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Optional disk-backed operation for data durability
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Shared-nothing architecture and multiple-host operation with
+ no single point of failure, enabling 99.999% availability
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Automatic data distribution across nodes; application
+ developers need not craft custom sharding or partitioning
+ solutions
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Support for variable-length data types (including
+ <literal role="type">BLOB</literal> and
+ <literal role="type">TEXT</literal>) not supported by
+ <literal role="se">MEMORY</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For a white paper with more detailed comparison of
+ <literal role="se">MEMORY</literal> with MySQL Cluster and a guide
+ for migrating from <literal role="se">MEMORY</literal> to Cluster,
+ see
+ <ulink url="http://www.mysql.com/why-mysql/white-papers/mysql-wp_cluster-7.0_Cluster_MEMORY.php">Scaling
+ Web Services with MySQL Cluster: An Alternative to the MySQL
+ Memory Storage Engine</ulink>.
+ </para>
+ </important>
+
<para>
Each <literal>MEMORY</literal> table is associated with one disk
file. The file name begins with the table name and has an extension
Modified: trunk/refman-6.0/se-memory-core.xml
===================================================================
--- trunk/refman-6.0/se-memory-core.xml 2010-07-14 18:44:10 UTC (rev 21730)
+++ trunk/refman-6.0/se-memory-core.xml 2010-07-14 19:00:24 UTC (rev 21731)
Changed blocks: 1, Lines Added: 104, Lines Deleted: 0; 3423 bytes
@@ -40,6 +40,110 @@
Features</citetitle>
</para>
+ <important>
+ <para>
+ Developers looking to deploy applications that use the
+ <literal role="se">MEMORY</literal> storage engine should consider
+ whether MySQL Cluster is a better choice. A typical use case for
+ the <literal role="se">MEMORY</literal> engine involves these
+ characteristics:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Operations such as session management or caching
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In-memory storage for fast access and low latency
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A read-only or read-mostly data access pattern (limited
+ updates)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ However, <literal role="se">MEMORY</literal> performance is
+ constrained by contention resulting from single-thread execution
+ and table lock overhead when processing updates. This limits
+ scalability when load increases.
+ </para>
+
+ <para>
+ MySQL Cluster offers the same features as the
+ <literal role="se">MEMORY</literal> engine with higher performance
+ levels, and provides additional features not available with
+ <literal role="se">MEMORY</literal>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Row-level locking and multiple-thread operation for low
+ contention between clients
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Scalability even with access mixes that include updates
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Optional disk-backed operation for data durability
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Shared-nothing architecture and multiple-host operation with
+ no single point of failure, enabling 99.999% availability
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Automatic data distribution across nodes; application
+ developers need not craft custom sharding or partitioning
+ solutions
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Support for variable-length data types (including
+ <literal role="type">BLOB</literal> and
+ <literal role="type">TEXT</literal>) not supported by
+ <literal role="se">MEMORY</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For a white paper with more detailed comparison of
+ <literal role="se">MEMORY</literal> with MySQL Cluster and a guide
+ for migrating from <literal role="se">MEMORY</literal> to Cluster,
+ see
+ <ulink url="http://www.mysql.com/why-mysql/white-papers/mysql-wp_cluster-7.0_Cluster_MEMORY.php">Scaling
+ Web Services with MySQL Cluster: An Alternative to the MySQL
+ Memory Storage Engine</ulink>.
+ </para>
+ </important>
+
<para>
Each <literal>MEMORY</literal> table is associated with one disk
file. The file name begins with the table name and has an extension
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r21731 - in trunk: . refman-5.1 refman-5.5 refman-6.0 | paul.dubois | 14 Jul |
