<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/2041/1/7/_/styles/combined.css?spaceKey=TOP&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/TOP/State+Replicator+Persistence+Options">State Replicator Persistence Options</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~khunt">Ken Hunt</a>
</h4>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >Each major component of an Asterisk SCF system has a corresponding State Replicator component. This State Replicator component is a sync for current state changes from an active component, and a source of state changes for standby components. Initial implementations of the State Replicator components are based on a simple C++ template which uses an in-memory cache of the replicated state. The cache is required to be able to provide the current state to late-joining backup components which may not have been online when the state updates were originally generated. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >{gliffy:name=Basic State <span class="diff-changed-words">Replication|version=1<span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">0</span><span class="diff-added-chars"style="background-color: #dfd;">1</span>}</span> <br></td></tr>
<tr><td class="diff-unchanged" > <br>Each state replication component, in its current implementation, represents a single point of failure in that the State Replicators themselves are not replicated. All of the State Replicators are, however, built to operate against define APIs. This allows us to address the robustness of the state replication mechanisms in the abstract. In other words, as we look to increase the robustness of the system, we can focus on replicating generic state, independent of the particular components involved. To provide a complete replication platform, we desire to exploit a general purpose, off-the-shelf solution for persisting data and replicating that data across systems. (Note: We fully expect 3rd parties may have reasons to build State Replicators on other persistence platforms than the one we choose to use.) <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h4><a name="StateReplicatorPersistenceOptions-Introduction"></a>Introduction</h4>
<p>Each major component of an Asterisk SCF system has a corresponding State Replicator component. This State Replicator component is a sync for current state changes from an active component, and a source of state changes for standby components. Initial implementations of the State Replicator components are based on a simple C++ template which uses an in-memory cache of the replicated state. The cache is required to be able to provide the current state to late-joining backup components which may not have been online when the state updates were originally generated. </p>
<map name='GLIFFY_MAP_12550532_Basic_State_Replication'></map>
<table width="100%">
<tr>
<td align="left">
<table>
<caption align="bottom">
</caption>
<tr>
<td>
<img style="border: none; width: 400px; height: 200px;"
usemap="#GLIFFY_MAP_12550532_Basic_State_Replication"
src="/wiki/download/attachments/12550532/Basic+State+Replication.png?version=11&modificationDate=1299872222729"
alt="A&#32;Gliffy&#32;Diagram&#32;named&#58;&#32;Basic&#32;State&#32;Replication"/>
</td>
</tr>
</table>
</td>
</tr>
</table>
<p>Each state replication component, in its current implementation, represents a single point of failure in that the State Replicators themselves are not replicated. All of the State Replicators are, however, built to operate against define APIs. This allows us to address the robustness of the state replication mechanisms in the abstract. In other words, as we look to increase the robustness of the system, we can focus on replicating generic state, independent of the particular components involved. To provide a complete replication platform, we desire to exploit a general purpose, off-the-shelf solution for persisting data and replicating that data across systems. (Note: We fully expect 3rd parties may have reasons to build State Replicators on other persistence platforms than the one we choose to use.)</p>
<h4><a name="StateReplicatorPersistenceOptions-CandidateTechnologies"></a>Candidate Technologies</h4>
<p>We want to identify an open-source solution that can do the following:</p>
<ul class="alternate" type="square">
<li>Persist dynamic data in near-real-time<br/>
(or give the appearance of persistence, in that another process can take over in the event of failure of an Asterisk SCF State Replicator.)</li>
<li>Replicate the data store</li>
<li>Simple to deploy</li>
<li>Simple to program</li>
<li>Lightweight install</li>
</ul>
<h5><a name="StateReplicatorPersistenceOptions-TheRelationalDatabaseQuestion"></a>The Relational Database Question </h5>
<p>The first choice is to decide if the solution would benefit from a relational database. While it's common for relational database systems to include a replication capability, there are no other compelling reasons to consider such a solution. Typical relational databases are typically accessed (from a programming POV) using SQL, and they excel when the requirements include such things as the ability to make fast queries on large datasets, or the ability to manage massive volumes of information. For our needs, the installation overhead of a relational database and the added complexity for the developer make it a poor fit. Our state data is a simple set of keyed value, which is added to and removed over time. When it's needed, it's needed in its entirety. </p>
<h5><a name="StateReplicatorPersistenceOptions-NonRelationalalternatives"></a>Non-Relational alternatives</h5>
<p>There is an ever growing field of non-relational data storage solutions. These include Object Oriented databases, document-oriented database, graph-oriented, and others. Some that we have looked at:</p>
<ul>
<li>CouchDB<br/>
License: Apache 2.0 <br/>
API: RESTful HTML interface, plugins for JavaScript/PHP/Ruby/Python/Erlang. <br/>
Accessible from C++ using cURLpp (MIT License), a C++ wrapper for libcURL (MIT License)</li>
</ul>
<ul>
<li>MongoDB<br/>
License: GNU AGPL v3.0.<br/>
API: We could enumerate all the cool features of MongoDB, such as it's C++, C#, Java, Erlan, Python APIs, it's cool binary JSON-like serialization format, and so forth... but it's license is just not something we're happy about. </li>
</ul>
<ul>
<li>Voldemort<br/>
License: Apache 2.0 <br/>
API: Relatively new project, lacking in documentation. Written in Java, and there is a C++ client demo that only runs on Linux. <br/>
Provides automatic replication. </li>
</ul>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/State+Replicator+Persistence+Options">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=12550532&revisedVersion=18&originalVersion=17">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/TOP/State+Replicator+Persistence+Options?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>