[jira] [Commented] (DERBY-7073) Can we override the underlying storage to implement a distributed Derby using Derby's subsubprotocol mechanism

["Richard N. Hillegas (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074846#comment-17074846 ] 

Richard N. Hillegas commented on DERBY-7073:
--------------------------------------------

I am not familiar with the capabilities of PolarDB (https://dbdb.io/db/polardb). It sounds as though it runs on top of a distributed file system. Derby's crash-recovery logic assumes that the data files (tables and indexes) are located on a single disk. Derby lets you put the recovery logs on a separate disk. You should be able to replace either of these disks with something like a RAID cluster in order to push much of the recovery problem into the hardware layer.

I don't understand your proposal about harnessing multiple Derby nodes into a single, logical storage layer.

You are on the right track to use a subprotocol in order to swap out the default file system with something fancier. As an example of how to do this, look at how in-memory databases (the memory subprotocol) were implemented.

Hope this helps,
-Rick


> Can we override the underlying storage to implement a distributed Derby using Derby's subsubprotocol mechanism
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-7073
>                 URL: https://issues.apache.org/jira/browse/DERBY-7073
>             Project: Derby
>          Issue Type: Task
>            Reporter: liaochuntao
>            Priority: Trivial
>
> /**
>  * derby.subSubProtocol.xxx
>  *<p>
>  *
>  * A new subsubprotocol can be defined by specifying the class that handles storage for the
>  * subsubprotocol by implementing the
>  * org.apache.derby.io.StorageFactory StorageFactory or
>  * org.apache.derby.io.WritableStorageFactory WritableStorageFactory interface. This
>  * is done using a property named db2j.subsubprotocol.<i>xxx</i> where <i>xxx</i> is the subsubprotocol name.
>  * Subsubprotocol names are case sensitive and must be at least 3 characters in length.
>  *<p>
>  *
>  * For instance:
>  *<br>
>  * derby.subSubProtocol.mem=com.mycompany.MemStore
>  *<br>
>  * defines the "mem" subsubprotocol with class com.mycompany.MemStore as its StorageFactory implementation.
>  * A database implemented using this subsubprotocol can be opened with the URL "jdbc:derby:mem:myDatabase".
>  *<p>
>  *
>  * Subsubprotocols "directory", "classpath", "jar", "http", and "https" are built in and may not be overridden.
>  */
>  
> Can we take advantage of this capability to implement a distributed contribution storage, with Derby acting as the computing layer and multiple Derby nodes contributing a storage layer, and realize Ploar DB similar to ali cloud, namely a distributed Derby



--
This message was sent by Atlassian Jira
(v8.3.4#803005)