JP2015062130A - 差分検索システム - Google Patents
差分検索システム Download PDFInfo
- Publication number
- JP2015062130A JP2015062130A JP2014222919A JP2014222919A JP2015062130A JP 2015062130 A JP2015062130 A JP 2015062130A JP 2014222919 A JP2014222919 A JP 2014222919A JP 2014222919 A JP2014222919 A JP 2014222919A JP 2015062130 A JP2015062130 A JP 2015062130A
- Authority
- JP
- Japan
- Prior art keywords
- server
- data
- search
- client
- update
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
本発明の目的は、通信量が少なくデータを更新できる技術を提供することにある。
本発明は、第1データベースを備え、データの変更履歴をバージョンで管理しているサーバと、通信回線網を介して前記サーバと接続され、前記サーバに同期して取得したデータとバージョンで構成される第2データベースを備えたクライアントとから成るクライアントサーバ型システムの検索システムであって、前記クライアントは、第1のネットワーク環境下では更新通知のみ前記サーバに送信し、前記第1のネットワーク環境より通信に有利な環境である第2のネットワーク環境下では、前記サーバに更新データを送信して、前記第1データベース及び前記第2データベースの同期を実行する。また、下記の不等式が成立する場合は、更新通知のみの方が効率的であるとの判定し、更新通知のみサーバに送信し、前記不等式が成立しない場合は更新通知のみの方が効率的でないと判定し、更新データを前記サーバに送信する。
まず、本発明の基本となる差分検索システムについて説明する。
図1は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図1に示すように、クライアントサーバシステム100は、サーバとなる情報管理装置2と、例えばインターネット網あるいは無線通信網3でクライアント機器となる情報端末装置1とから構成されている。情報管理装置(以下の説明では、サーバとも称する)2は、図1に示すように、データベース24に接続されている。データベース24は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置2は、専用機器である必要は無い。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのIDとで把握されるようになっている。これらの詳細については、後述する。
(第1の実施形態)
図3は、第1の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。クライアント機器である情報端末装置1はサーバである情報管理装置2において、データベースの更新が行われると、現在のバージョンに対して1つインクリメント(バージョンを+1する)とされる。更新の内容は変更履歴として管理される。変更履歴は、バージョンと対象となるデータのIDから成り立っている。更新に併せて、差分把握可能範囲が設定される。この差分把握可能範囲は、言わば、差分検索が可能な範囲を意味する。極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するためのものである。クライアント機器が自ら保有しているデータベースに対して検索を行う際に、既にサーバ側ではデータベースが更新された結果、削除あるいは変更済みのデータが未だ存在している可能性がある。これら削除あるいは変更済みのデータに対して検索を行うことは全く無意味である。そこで、クライアント機器が自ら保有しているデータベースに対して検索を行う前に、クライアント機器において、該当データの「無効化処理」を行う。「無効化処理」は、サーバで「差分把握」を行い、クライアント機器はサーバから該当するデータIDを受け取って「無効化処理」をする。「差分検索」では、情報管理装置と情報端末装置間で、それぞれのデータベースのデータに差分が存在するか否か問い合わせを行う。情報管理装置は「変更履歴」から差分データについて検索して、情報端末装置に検索結果を送信する。
まず、情報端末装置のバージョン:Vcを取得する(ステップS1701)。次いで、情報管理装置のバージョン:Vsを取得する(ステップS1702)。次いで、両者のバージョンを比較する(ステップS1703)。Vc=Vsであれば、Vsと結果:R=「変更データ無し」を情報端末装置に通知する(ステップS1705)。Vc=Vsでなければ、変更履歴から差分把握可能範囲:Vaを取得する(ステップS1704)。次いで、Va>Vcかどうかを判断する(ステップS1706)。Va>Vcであれば、結果:R=「差分検索不可」を情報端末装置に通知する(ステップS1711)。Va>Vcでなければ、データベースから変更履歴を使い、差分IDsを作成する(ステップS1707)。次いで、変更が削除のみかどうかを判断する(ステップS1708)。変更が削除のみでなければ、Vsと差分ID:IDsを情報端末装置に通知する(ステップS1709)。変更が削除のみであれば、結果:R=「差分削除のみ」Vsと差分ID:IDsを情報端末装置に通知する(ステップS1710)。
まず、差分把握完了フラグ=ONかどうか判断する(ステップS1901)。差分把握完了フラグ=ONでなければ、接続処理(情報管理装置にVcを渡す)を行う(ステップS1902)。続いて、差分IDの送受信を行い(ステップS1903)、差分IDの除去を実行する(ステップS1904)。一方、差分把握完了フラグ=ONであれば、Vc≠0かどうか判断する(ステップS1905)。Vc≠0であれば、情報端末装置のデータベースから検索を実行する(ステップS1906)。次いで、サーバフラグ=ONかどうか判断する(ステップS1907)。一方、Vc≠0でなければ、直ちにステップS1907のサーバフラグ=ONかどうかの判断に移る。サーバフラグ=ONであれば、情報管理装置から検索を行う(ステップS1908)。そして、検索結果を表示する(ステップS1909)。 図20は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でVcとVsを用いてSQL文を作成し(ステップS2001)、SQL文を情報管理装置側へ送信する(ステップS2002)。情報管理装置側では、SQL文を受信する(ステップS2003)と、変更履歴を用いて差分データから検索を実行する(ステップS2004)。情報管理装置は、検索結果を送信し(ステップS2005)、情報端末装置は検索結果を取得する(ステップS2006)。図21は、上記したステップS2004の変更履歴を用いた差分データからの検索処理を説明する図である。情報管理装置は、SELECTWHERE 2<Ver AND Ver≦4とのSQL文を受信すると(ステップS2101)、SELECT文を実行する(ステップS2102)。図21に示す例では、変更履歴から、バージョン3ではnode2に変更を加え、バージョン4ではnode4に変更が加えられている。よって、情報管理装置が実行すべき差分検索は、node2、node4のみを検索対象とすることがわかる。したがって、検索に要する時間も極めて短時間である。このように、本実施形態によれば、差分処理なので検索対象が少なくて済み、差分検索結果のデータサイズは差分データサイズよりもはるかに小さいのでサーバの処理量が著しく減少させることができ、多くのクライアント機器をケアすることができる。さらに、バージョン管理により、効率よく最新データの把握ができる。
図22は、第2の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。第2の実施形態では、言わば、変更履歴を管理するために必要となるメモリの削減をその狙いとするものである。そのため、(1)変更履歴欄がいっぱいであれば、古いものを削除する、(2)変更履歴欄に同じデータIDが存在していたら、最新のものにまとめる、(3)変更履歴で把握できる範囲外のバージョンならば、あえて差分検索しない等を骨子としている。図23は、変更発生時の変更履歴欄の更新処理であって、削除のみの変更の場合の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されている(ステップS2301)。次いで、変更内容が削除以外にないかどうか判定する(ステップS2302)。YESであれば、DELETE ONLYフラグをONにする(ステップS2303)。ここでは、node4を削除するのみの変更が、バージョン“3”として、行われ、DELETE ONLYフラグをONにしている。次いで、バージョンを+1している(ステップS2304)。図24は、変更発生時の変更履歴欄の更新処理であって、データを節約する場合の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されている(ステップS2401)。次いで、変更履歴に同じデータIDが存在するかどうか判定する(ステップS2402)。YESであれば、変更履歴の古いものを削除する(ステップS2403)。ここでは、node4を対象とする変更が過去においてバージョン“2”でなされているので、バージョン“2”の履歴を削除し、node4を対象とする変更履歴をバージョン“4”のものにまとめている。次いで、バージョンを+1している(ステップS2404)。図25は、変更発生時の変更履歴欄の更新処理であって、古い差分情報は削除する場合の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されている(ステップS2501)。次いで、変更履歴がいっぱいかどうか判定する(ステップS2502)。YESであれば、古い差分情報を削除する(ステップS2503)。ここでは、node12を対象とするバージョン“1”の変更履歴を消すことになる。バージョン“1”の変更履歴が消されと、変更履歴の最も古いバージョン:Voを差分把握可能範囲:Vaに代入する(ステップS2504)。ここでは、最も古いバージョンが“2”となり、差分把握可能範囲もバージョン“2”となっている。次いで、バージョンを+1している(ステップS2505)。
まず、更新要求の受付後、更新処理を実行する(ステップS2601)。次いで、変更したノードを変更履歴に追加する(ステップS2602)。次いで、サーバのバージョンを+1し、Vs=Vs+1と設定する(ステップS2603)。続いて、変更内容は削除以外にないかを判断する(ステップS2604)。削除のみならば、DELETE ONLYフラグをONにする(ステップS2605)。フラグ設定後、変更履歴に同じIDがあるかを判断する(ステップS2606)。変更内容が削除以外にもある場合もステップS2606に移る。変更履歴に同じIDがあれば、変更履歴の古いものを削除する(ステップS2607)。削除後、変更履歴がいっぱいかどうかを判断する(ステップS2608)。変更履歴に同じIDがない場合もステップS2608に移る。変更履歴がいっぱいであれば、古い差分情報を削除し(ステップS2609)、変更履歴の最も古いバージョンを差分可能範囲に代入する(ステップS2610)。次いで、変更履歴を上位概念でまとめ(ステップS2611)、結果を返却する(ステップS2612)。変更履歴がいっぱいでない場合には、ステップS2611以降に移る。第2の実施形態によれば、第1の実施形態での効果に加えて、変更履歴の管理をより効率的に行うことができる。
図27は、第3の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。第3の実施形態では、バージョンアップに伴う処理をより効率的に行うことに狙いがある。そのため、変更履歴の管理をより上位の概念で行う、例えば、図6のTable単位あるいはPage単位でまとめるものである。
まず、同じページのIDをカウントする(ステップS2901)。Pageでまとめられるかどうかを判断する(ステップS2902)。Pageでまとめられる場合には、同じページのIDを変更履歴から削除する(ステップS2903)。次いで、同じテーブルのIDをカウントする(ステップS2904)。Pageでまとめられない場合には、直ちにステップS2904に移る。次いで、Tableでまとめられるかどうかを判断する(ステップS2905)。Tableでまとめられる場合には、同じテーブルのIDを変更履歴から削除し(ステップS2906)、上位概念でのまとめを終了する。Tableでまとめられない場合にも、上位概念でのまとめを終了する。
図30は、第4の実施形態にかかる検索システムを説明する図である。第4の実施形態では、情報管理装置での検索結果の通信量のさらなる低減を図るもので、差分検索に関して、検索結果と差分データから同期判断し、同期したほうが良いと判断した場合には、同期データを送信し、かかる同期判断は段階的に行ってもよい、等を骨子としている。ここでは、図30に示すように、差分データDsと、差分検索結果Rsのデータサイズを比較する。図31は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でVcとVsを用いてSQL文を作成し(ステップS3101)、SQL文を情報管理装置側へ送信する(ステップS3102)。情報管理装置側では、SQL文を受信する(ステップS3103)と、変更履歴を用いて差分データから検索を実行する(ステップS3104)。次いで、差分データサイズ:Sdを取得する(ステップS3105)。続いて、検索結果データサイズ:Srを取得する(ステップS3106)。そして、差分データサイズ:Sdと積分の差分検索データサイズ:ΣSrについて、Sd>ΣSrかどうかを判断する(ステップS3106)。情報管理装置は、Sd>ΣSrでなければ、検索結果の代わりに差分データを送信し(ステップS3108)、Sd>ΣSrであれば検索結果を送信する(ステップS3109)。情報端末装置はデータを取得し(ステップS3110)、データが差分データかどうかを判断する(ステップS3111)。差分データであれば、差分データをデータベースにアップデートする(ステップS3112)。Vc=Vsとし(ステップS3113)、サーバフラグ=OFFと設定する(ステップS3114)。
第5の実施形態では、情報管理装置での検索結果の通信量のさらなる低減を図るものである。図32は、第5の実施形態にかかる検索システムを説明する図である。ここでは、図32に示すように、バージョンごとのデータで、差分データDsと、差分検索結果Rsのトータルサイズを比較する。
まず、情報管理装置への検索要求は、情報端末装置側でVcとVsを用いてSQL文を作成し(ステップS3301)、SQL文を情報管理装置側へ送信する(ステップS3302)。情報管理装置側では、SQL文を受信する(ステップS3303)と、N=N+1とカウントアップ(ステップS3304)した後、変更履歴を用いて差分データから検索を実行し、データを作成する(ステップS3305)。情報管理装置は、情報端末装置に送信データ:S の送信を行う(ステップS3306)。情報端末装置はデータを取得し(ステップS3307)、データに差分データがあるかどうかを判断する(ステップS3308)。差分データがあれば、差分データをデータベースにアップデートする(ステップS3309)。Vc=Vdと設定し(ステップS3310)、Vc=Vsかどうかを判断する(ステップS3311)。Vc=Vsであれば、サーバフラグ=OFFとする(ステップS3312)。一方、データに差分データがない場合には、ステップS3312に移る。Vc=Vsでない場合には終了する。
次に、上記の差分検索を行うことが可能な差分検索システムでのデータ更新方法について説明する。
1.後発のロックはあきらめる。
2.先にロックをかけたクライアントによるロックを解除して、後発のクライアントによるロックを行う。後発のクライアントは先にロックをかけたクライアントに問い合わせて、内容を確認し、上記1.または2.のいずれかを選択する。
本発明では、クライアントが更新データをサーバに送信するか否かを判定するための情報の一つとして、「稼働率」を利用する。稼働率は以下の式で算出される。
前回と同様、更新データは同期のためのデータであり、(更新データを送付しない場合の送信データ量)≦更新データを送付した場合の送信データ量が成立する時、本発明の方式は効率的となる。よって
また、上記式は
この判定式を使った予測によってデータを送信すべきかどうか決定できる。とりわけ最初の判断と、検索要求が多く来た時に利用可能である。
p=23/(23+1)=0.958
さらに、更新データ量Dは、差分検索のためのデータ量Rの10倍(D=10R)とすると、前記不等式を変形してn≦D/(R×(1−p))=10/0.04=250となり、結局250回/日の検索要求が一定間隔できても、結果効果的であることがわかる。
以下、本システムの基本的な動作例について説明する。
(1)更新要求クライアントによる遠距離更新時のユーザ更新要求
(2)サーバによる遠距離更新時のユーザ更新要求受付
(3)検索要求クライアントによる検索実行
(4)サーバによるユーザ参照要求受付
(5)サーバによる差分検索要求、更新要求クライアントによる差分検索応答
(6)更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付
以下、上記手順の具体的内容について述べる。
図41は、上記(1)更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる遠距離更新時のユーザ更新要求を説明する。
上記通常更新(更新データ)若しくは更新通知を受け付けたサーバ(より詳しくは命令制御部22、以下同じ)は、ユーザ更新要求受付を実行する。図42は、上記(2)サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャートである。以下このフローチャートを参照しながらサーバによる遠距離更新時のユーザ更新要求受付の処理内容を説明する。
以上で、サーバによるユーザ更新要求受付が終了する。
上記サーバがユーザ更新要求受付を終了したのち、検索要求クライアントが検索要求をサーバに送信したものとする。このとき検索要求クライアントによる検索実行が行われる。図43は、上記(3)検索要求クライアントによる検索実行の例を示したフローチャートである。以下このフローチャートを参照しながら検索要求クライアントによる検索実行の処理内容を説明する。
以上で、検索要求クライアントによる検索実行が終了する。
検索要求クライアントから検索要求を受け付けたサーバは、ユーザ参照要求受付処理を実行する。図44は、上記(4)サーバによるユーザ参照要求受付の例を示したフローチャートである。以下このフローチャートを参照しながらユーザ参照要求受付処理の内容を説明する。
以上で、ユーザ参照要求受付処理が終了する。
検索要求クライアントから検索要求を受け付けたサーバは、更新クライアントに対して差分検索要求を出し、この差分検索要求を受け付けた更新要求クライアントは差分検索応答を行う。
まず、更新要求クライアントは、サーバ側の差分検索要求のステップS4601においてサーバから送信された差分検索要求を受け取る(S4608)。次に、更新要求クライアントは、この差分検索要求に応じて、自己のデータベースを用いて差分検索を実行する(S4609)。次に、更新要求クライアントは今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定する(S4610)。
具体的には、下記式に基づいてS4610の判定が行われる。
弱いネットワーク環境下にあった更新要求クライアントが強いネットワーク環境下に入った場合、更新要求クライアントによる更新要求並びにサーバによるユーザ更新要求受付が行われる。図47は、上記更(6)新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付を説明する。
完全同期処理を開始した更新要求クライアントはまず、自分のデータベースのVersionをサーバに通知する(S4709)。サーバは更新要求クライアントからデータベースのVersionを得る(S4710)と、更新要求クライアントに渡すべき差分となるデータを生成する(S4711)。次にサーバは、差分となるデータを更新要求クライアントに送信する(S4712)。更新要求クライアントはサーバから差分となるデータを受信する(S4713)。更新クライアントは受信した差分となるデータを自己のデータベースに更新させる(S4714)。これで、更新クライアント及びサーバ間のデータベース完全同期が完了する。
本発明は、下記のような状況下でとりわけ有効である。
1.サーバ、クライアント間が近距離では安価で高速な通信ができ、遠距離では高価で低速でも通信が可能であること。
このような環境下で、本発明は、近距離では同期による更新をし、遠距離では本提案を実施する。
2.一定間隔で、データベースがリフレッシュできること
充電のついでに完全同期できるなど、そのような完全同期がある期間内には行われる環境であること。
3.クライアント側で入力されるような、更新データが大量であるが、検索対象になりにくい環境下であること。
同期するまで、当面、検索されないようなものほど本発明は効果がある。
上記において「近距離」とは例えば、(通信の)コストが小さい環境を意味し、「遠距離」とは例えば、(通信の)コストが大きい環境を意味する。
ここでいう「コスト」とは、通信に伴う料金(課金額)や、通信速度、レイテンシィ、電力消費量などを一つ乃至は複数考慮して決定する定量的なものを意味する。
本発明によれば、以下のメリットを享受できる。
1.データを更新する際、悪い通信環境での通信量を減らすことができるため、(ネットワーク管理者から見てネットワークトラフィックが減り、ユーザから見た場合に通信費用が減る。
2.サーバの負担を減らすことも可能となる。
第1データベースを備え、データの変更履歴をバージョンで管理しているサーバと、通信回線網を介して前記サーバと接続され、前記サーバに同期して取得したデータとバージョンで構成される第2データベースを備えたクライアントとから成るクライアントサーバ型システムの検索システムであって、
前記クライアントは、
第1のネットワーク環境下では更新通知のみ前記サーバに送信し、前記第1のネットワーク環境より通信に有利な環境である第2のネットワーク環境下では、前記サーバに更新データを送信して、前記第1データベース及び前記第2データベースの同期を実行し、
前記サーバから差分検索要求を受け取った場合、今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定し、今まで送った更新データのデータ量の合計値が、前記サーバに送るべき更新データのデータ量を超えると判定した場合、前記サーバに更新データを送信し、一方今まで送った更新データのデータ量の合計値が、前記サーバに送るべき更新データのデータ量を超えないと判定した場合には差分検索結果を前記サーバに送信する
差分検索システムであっても良い。
Claims (2)
- 第1データベースを備え、データの変更履歴をバージョンで管理しているサーバと、通信回線網を介して前記サーバと接続され、前記サーバに同期して取得したデータとバージョンで構成される第2データベースを備えたクライアントとから成るクライアントサーバ型システムの検索システムであって、
前記クライアントは、
第1のネットワーク環境下では更新通知のみ前記サーバに送信し、前記第1のネットワーク環境より通信に有利な環境である第2のネットワーク環境下では、前記サーバに更新データを送信して、前記第1データベース及び前記第2データベースの同期を実行し、
下記の不等式
が成立する場合は、更新通知のみの方が効率的であるとの判定し、更新通知のみサーバに送信し、前記不等式が成立しない場合は更新通知のみの方が効率的でないと判定し、更新データを前記サーバに送信する
ことを特徴とする差分検索システム。
但し、Dは更新を行うために送信しなければならない更新データの送信データ量、nは差分検索を含むすべての検索発生回数、Rは差分検索のためのデータ量、pは本差分検索システムの稼働率。 - 前記クライアントは、前記サーバから差分検索要求を受け取った場合、今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定し、今まで送った更新データのデータ量の合計値が、前記サーバに送るべき更新データのデータ量を超えると判定した場合、前記サーバに更新データを送信し、一方今まで送った更新データのデータ量の合計値が、前記サーバに送るべき更新データのデータ量を超えないと判定した場合には差分検索結果を前記サーバに送信する
ことを特徴とする請求項1に記載の差分検索システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014222919A JP5847912B2 (ja) | 2014-10-31 | 2014-10-31 | 差分検索システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014222919A JP5847912B2 (ja) | 2014-10-31 | 2014-10-31 | 差分検索システム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010131475A Division JP2011257959A (ja) | 2010-06-08 | 2010-06-08 | 差分検索システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2015062130A true JP2015062130A (ja) | 2015-04-02 |
JP5847912B2 JP5847912B2 (ja) | 2016-01-27 |
Family
ID=52821437
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014222919A Active JP5847912B2 (ja) | 2014-10-31 | 2014-10-31 | 差分検索システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5847912B2 (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000122907A (ja) * | 1998-10-20 | 2000-04-28 | Mitsubishi Electric Corp | 更新履歴管理装置及び更新履歴管理方法 |
JP2004054833A (ja) * | 2002-07-24 | 2004-02-19 | Sharp Corp | サーバ、クライアント、およびクライアントサーバシステム |
JP2010282360A (ja) * | 2009-06-03 | 2010-12-16 | Toshiba Corp | 検索システムおよび検索方法 |
-
2014
- 2014-10-31 JP JP2014222919A patent/JP5847912B2/ja active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000122907A (ja) * | 1998-10-20 | 2000-04-28 | Mitsubishi Electric Corp | 更新履歴管理装置及び更新履歴管理方法 |
JP2004054833A (ja) * | 2002-07-24 | 2004-02-19 | Sharp Corp | サーバ、クライアント、およびクライアントサーバシステム |
JP2010282360A (ja) * | 2009-06-03 | 2010-12-16 | Toshiba Corp | 検索システムおよび検索方法 |
Also Published As
Publication number | Publication date |
---|---|
JP5847912B2 (ja) | 2016-01-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2410431A1 (en) | Method and system for data replication management | |
EP2474911B1 (en) | Data synchronization system and data synchronization method | |
CN110659430B (zh) | 一种支持多区块链网络的区块链浏览方法 | |
JP4944160B2 (ja) | 複数のリアルタイム・センサを検索する方法及び装置 | |
CN111258978B (zh) | 一种数据存储的方法 | |
US11599591B2 (en) | System and method for updating a search index | |
US20070100807A1 (en) | Data searching system, method of synchronizing metadata and data searching apparatus | |
WO2020024903A1 (zh) | 用于搜索区块链数据的方法、设备及计算机可读存储介质 | |
JP2012174113A (ja) | ファイルストレージシステム及び記憶制御方法 | |
JP2019133579A (ja) | 処理プログラム、およびイベント処理方法 | |
EP4024815A1 (en) | Data uploading method, system and apparatus, and electronic device | |
WO2003055185B1 (en) | Database driven methods and systems for real time call tracing | |
JP2011257959A (ja) | 差分検索システム | |
US8818971B1 (en) | Processing bulk deletions in distributed databases | |
CN109947718A (zh) | 一种数据存储方法、存储平台及存储装置 | |
JP5847912B2 (ja) | 差分検索システム | |
JP2010282360A (ja) | 検索システムおよび検索方法 | |
CN108810092B (zh) | 网络访问方法和装置、电子设备、计算机可读存储介质 | |
JP5649437B2 (ja) | データベース・システム、並びにそのクライアント | |
CN109086414B (zh) | 用于搜索区块链数据的方法、装置及存储介质 | |
CN112671922B (zh) | 工业互联网数据处理系统及方法 | |
CN110502534A (zh) | 数据库高速缓存 | |
JP5649457B2 (ja) | データベース・システム、並びにそのクライアント | |
US20190370350A1 (en) | Dynamic Configurability of Web Pages | |
US20190384802A1 (en) | Dynamic Configurability of Web Pages Including Anchor Text |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20150717 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150728 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150918 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20151027 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20151125 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 5847912 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |