<html>
<head>
    <base href="https://wiki.asterisk.org/wiki">
            <link rel="stylesheet" href="/wiki/s/2041/1/7/_/styles/combined.css?spaceKey=TOP&amp;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" >API: Relatively new project, somewhat lacking in documentation. Written in Java, and there is a C++ client demo that only runs on Linux.  <br>Provides automatic replication.  <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;"> <br>* Tokyo Cabinet <br>License: LGPL <br> <br>* Constant Database (CDB) <br>License: CDB Library is public domain. The rest of the package is [license-free software|http://en.wikipedia.org/wiki/License-free_software].  <br>A CDB instance can only be rebuilt, not modified. (Hence, the &quot;constant&quot;). Not applicable, since we need to be able to remove keys from the database.  <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <p>&lt;DRAFT... Work in progress&gt;</p>

<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 sink 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 store of the replicated state. The state store 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=13&amp;modificationDate=1299872325217"
                             alt="A&amp;#32;Gliffy&amp;#32;Diagram&amp;#32;named&amp;#58;&amp;#32;Basic&amp;#32;State&amp;#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 well-defined 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: As with all Asterisk SCF components, we fully expect 3rd parties will have reasons to build alternative implementations using different technologies than the persistence platforms that we choose to use.)</p>

<h4><a name="StateReplicatorPersistenceOptions-CandidateTechnologies"></a>Candidate Technologies</h4>

<p>To build component State Replicators that are not single points of failure, we want to identify an open-source solution that can do the following:</p>
<ul class="alternate" type="square">
        <li>Replicate the state store across servers in near-real-time. The low-latency requirement is driven by the highly dynamic nature of the state being replicated.</li>
        <li>Persist the state store (or provide the appearance of persistence, in that another process can take over in the event of failure of an Asterisk SCF State Replicator.)</li>
</ul>


<p>In addition, we want the solution to have the following characteristics: </p>
<ul class="alternate" type="square">
        <li>Simple to deploy</li>
        <li>Simple to program to</li>
        <li>Lightweight installation.</li>
</ul>


<p>We've examined several database technologies with these goals in mind. </p>

<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 accessed (from a programming POV) using SQL, and thus require additional programming expertise for the Asterisk SCF developer. These applications are often fairly large installations due to their inherent complexity, requiring significant disk storage requirements, services to manage connections to the database, tools for administering the databse, etc. While relational databases 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, they don't offer much for our purposes other than the ability to replicate across servers. Even that feature is not based on standards, nor universally available across the various implementations. </p>

<p>For our needs, the installation overhead of a relational database and the added complexity for the developer seems to be a poor fit. Our state data is a simple set of keyed values, which are added to and removed over time. The State Replicator is pushing updates to all standby listeners in real-time, so when the data store is needed (for late joiners), it's needed in its entirety. The query engine of a relation database doesn't appear to be any benefit. </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 databases, graph-oriented, and others. Besides the persistence / structure mechanisms, we are also interested in how each of the technologies approach replication. With our stated need of near-real-time replication due to the highly dynamic nature of the data, many database replication schemes that work fine for other purposes will not provide the solution we are looking for. </p>

<p>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)<br/>
Replication: A peer-based distributed system that allows peers to access and update shared data while disconnected, and then perform bi-directional replication of updates. (This is not unlike git repository approach!) While convenient for things like synchronizing with a laptop that is offline for a lot of the time, it is not designed to be particularly fast at replication. </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, fast replication, 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, somewhat lacking in documentation. Written in Java, and there is a C++ client demo that only runs on Linux. <br/>
Provides automatic replication. </li>
</ul>


<ul>
        <li>Tokyo Cabinet<br/>
License: LGPL</li>
</ul>


<ul>
        <li>Constant Database (CDB)<br/>
License: CDB Library is public domain. The rest of the package is <a href="http://en.wikipedia.org/wiki/License-free_software" class="external-link" rel="nofollow">license-free software</a>. <br/>
A CDB instance can only be rebuilt, not modified. (Hence, the "constant"). Not applicable, since we need to be able to remove keys from the database. </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=29&originalVersion=28">View Changes</a>
                |
        <a href="https://wiki.asterisk.org/wiki/display/TOP/State+Replicator+Persistence+Options?showComments=true&amp;showCommentArea=true#addcomment">Add Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>