1353 |
\end{figure} |
\end{figure} |
1354 |
|
|
1355 |
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=11cm, height=8cm]{storm_query_blockid.eps} |
|
|
\caption{Locating owner peer for a given block ID} |
|
|
\label{fig:storm_query_blockid} |
|
|
\end{figure} |
|
1356 |
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=11cm, height=8cm]{storm_query_urn5.eps} |
|
|
\caption{Locating owner peer for a given urn-5} |
|
|
\label{fig:storm_query_urn5} |
|
|
\end{figure} |
|
1357 |
|
|
1358 |
|
|
1359 |
|
|
1649 |
|
|
1650 |
\parbox{90pt}{Query traffic} & |
\parbox{90pt}{Query traffic} & |
1651 |
\parbox{100pt}{$O(n)/O(n^{2})$} & |
\parbox{100pt}{$O(n)/O(n^{2})$} & |
1652 |
\parbox{100pt}{$O(1)/O(log n)$} |
\parbox{100pt}{$O(1)/O(\log{n})$} |
1653 |
\\ \hline |
\\ \hline |
1654 |
|
|
1655 |
\parbox{90pt}{Guaranteed data lookup} & |
\parbox{90pt}{Guaranteed data lookup} & |
1780 |
|
|
1781 |
-for DHTs and SWNs: |
-for DHTs and SWNs: |
1782 |
|
|
1783 |
Please notice: In this approach, DHT doesn't store the actual block, only the values for locating the data from the system |
|
1784 |
|
|
1785 |
|
\section{Analysis} |
1786 |
|
|
1787 |
|
In this section we analyse the costs of locating Storm block with a given identifier |
1788 |
|
and urn-5 random string. |
1789 |
|
|
1790 |
|
\subsection{Assumptions} |
1791 |
|
We use tightly structured ovelay's DOLR method. Each peer hosts the data, |
1792 |
|
overlay maintains the \emph{pointers} of the data. Furthermore, each peer maintains |
1793 |
|
following data structures for local operations: one data structure for listing all |
1794 |
|
key/value-pairs; one data structure for scroll blocks; one data structure for |
1795 |
|
pointer blocks. Key/value-pairs are as follows: |
1796 |
|
|
1797 |
|
For scroll blocks |
1798 |
|
|
1799 |
|
|
1800 |
|
\subsection{Algorithms} |
1801 |
|
|
1802 |
|
|
1803 |
|
|
1804 |
|
\begin{itemize} |
1805 |
|
\item Data lookup with a given scroll block's identifier |
1806 |
|
\begin{enumerate} |
1807 |
|
\item Submit query using scroll block's identifier |
1808 |
|
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier |
1809 |
|
\item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator |
1810 |
|
\item Query originator requests hosting node to return the scroll block |
1811 |
|
\end{enumerate} |
1812 |
|
\end{itemize} |
1813 |
|
|
1814 |
|
|
1815 |
|
\begin{itemize} |
1816 |
|
\item Data lookup with a given urn-5 random string returning most recent scroll block |
1817 |
|
\begin{enumerate} |
1818 |
|
|
1819 |
|
\item Query originator locally compute a hash for given urn-5 random string |
1820 |
|
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of urn-5 |
1821 |
|
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes |
1822 |
|
\item Query originator requests hosting node to return the scroll block |
1823 |
|
\end{enumerate} |
1824 |
|
\end{itemize} |
1825 |
|
|
1826 |
|
\begin{itemize} |
1827 |
|
\item Data lookup with a given urn-5 random string returning scroll block(s) for a given date and time range |
1828 |
|
\begin{enumerate} |
1829 |
|
|
1830 |
|
\item Query originator locally compute a hash for given urn-5 random string |
1831 |
|
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of urn-5 |
1832 |
|
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes |
1833 |
|
\item Query originator requests hosting node to return the scroll block |
1834 |
|
\end{enumerate} |
1835 |
|
\end{itemize} |
1836 |
|
|
1837 |
|
|
1838 |
|
|
1839 |
|
|
1840 |
|
Req. 1: |
1841 |
|
-each node maintains a local hash-table based data structure (urn-5 name -> most recent local block ID) for every urn-5 names |
1842 |
|
which node hosts. The most recent block is topmost --> we don't have to check all blocks and their urn-5 associations to get the most recent |
1843 |
|
Req. 2: |
1844 |
|
-all urn-5 name mappings are stored as <key, value[ ]>, where the key is urn-5 name's hash and value is a record containing |
1845 |
|
block ID and timestamp of that block. So, when we store a block in our system first time, we have to create a new key-value: |
1846 |
|
%<hash_of_urn_5_name, [block id, block timestamp]> and route this mapping to node which is "closest" to a hash value. Now when we want to find the most |
1847 |
|
recent block associated with a specific urn-5 name, we do: |
1848 |
|
|
1849 |
|
|
1850 |
|
|
1851 |
|
In this approach, we don't have to perform additional searching and sorting of mappings. And of course, we know that for given urn-5, only one node |
1852 |
|
hosts *all* the block information ("block history") for the urn-5, since mappings are mapped to a single node, closest to urn-5 hash value. |
1853 |
|
Again, this should work fine under existing DHTs (and SWTs ?). |
1854 |
|
|
1855 |
|
Some simple analysis: |
1856 |
|
-there are more key-value pairs in the system for additional urn-5 --> block associations |
1857 |
|
-however, I don't think this is an issue, since data's size is small |
1858 |
|
-efficiency: find node which hosts urn-5 names + find node which hosts blocks associated with urn-5 name: logn + logn = 2logn (logarithmical) |
1859 |
|
|
1860 |
|
-for FBS and others: |
1861 |
|
-there is no very efficient (simple) methods for finding urn-5 name associated with the most recent block |
1862 |
|
-one simple proposal is that when we visit to each node (first idea above), get only the most recent one and compare them (or greedy approach: dismiss currently |
1863 |
|
most recent block as we visit to nodes, if newer block have been found) |
1864 |
|
|
1865 |
|
|
1866 |
|
Please notice: In this approach, DHT doesn't store the actual block, only the values for locating the data from the system |
1867 |
|
|
1868 |
Req. 1: |
Req. 1: |
1869 |
-each node maintains a local hash-table based data structure (urn-5 name -> most recent local block ID) for every urn-5 names |
-each node maintains a local hash-table based data structure (urn-5 name -> most recent local block ID) for every urn-5 names |
1888 |
-there is no very efficient (simple) methods for finding urn-5 name associated with the most recent block |
-there is no very efficient (simple) methods for finding urn-5 name associated with the most recent block |
1889 |
-one simple proposal is that when we be that we visit to each node (first idea above), get all blocks which matches to given properties |
-one simple proposal is that when we be that we visit to each node (first idea above), get all blocks which matches to given properties |
1890 |
|
|
1891 |
|
|
1892 |
\section{Analysis} |
|
1893 |
|
\begin{figure} |
1894 |
|
\centering |
1895 |
|
\includegraphics[width=11cm, height=8cm]{storm_query_blockid.eps} |
1896 |
|
\caption{Locating owner peer for a given block ID} |
1897 |
|
\label{fig:storm_query_blockid} |
1898 |
|
\end{figure} |
1899 |
|
|
1900 |
|
\begin{figure} |
1901 |
|
\centering |
1902 |
|
\includegraphics[width=11cm, height=8cm]{storm_query_urn5.eps} |
1903 |
|
\caption{Locating owner peer for a given urn-5} |
1904 |
|
\label{fig:storm_query_urn5} |
1905 |
|
\end{figure} |
1906 |
|
|
1907 |
\section{Open issues and future work} |
\section{Open issues and future work} |
1908 |
|
|