Tablestoreに設立されたWifi設備監督管理システムアーキテクチャが実現される。
Wifi設備の監督管理
会社は監視システムを通じてWifi設備の属性を維持し、Wifi設備の監視データを収集する。Wifiデバイス上、オフラインが必要な場合、レギュレータシステムを通じてデバイスの追加、オフラインが完了し、同時にシステムを介してデバイス属性情報を修正し、追加することができます。設備がオンラインになったら、定期的に監視データをシステムに送って、設備監視データの収集を完成します。収集データには、cpu、メモリ、接続数、Wanポートの流量と流速、2.4 Gと5 Gモジュールのチャネルデータなどが含まれています。
監視データの指標を分析し、設備の運行状態を分析することにより、問題設備の運行状態を注意報、警報に変更する。システムの助けを借りて、ネットワーク部門は問題設備リストを素早く取得し、設備の分布を理解し、履歴監視指標を検索することができます。同時に、古いデバイスを正確にロックし、デバイスのアップグレードを容易にしたり、長期的な負荷率の高い位置にWifiデバイスを拡張するためのデータの根拠を提供したりすることができます。
機能ニーズ
1、Wifi設備を管理し、システムを通じて新設備、オフラインの古い設備をオンラインする。
2、システムはグループ管理能力、ラベル検索能力を持っています。
3、高合併量監視データの収集能力。
4、あらゆる設備の地理的分布を管理する。
5、あるエリア内の全ての設備の位置を調べます。
6、【ある設備】の【ある期間】【異なる指標】における監視データを検索する。
7、低コストの持久化のすべてのデータ、データの潜在価値を掘り起こすなど…。
システムの例は以下の通りです。公式サイトのコンソールアドレス：プロジェクトのサンプル
技術上の需要
通常、ユーザーは設計案において、次の4つの主要な技術ニーズを重点的に考慮することができる。
第一に、強力な照会、統計能力が必要で、Wifi設備の管理を実現する。
第二に、設備の高合併をサポートするモニタリングデータの収集には、データベースの強力な書き込みが必要です。
第三に、データの持続化の需要はデータの膨張を招きますが、履歴監視データは冷媒データが多く、保存コストはできるだけ低い必要があります。第四に、監視データは将来に潜在価値が高く、製品の下流にはより良い計算生態が必要である。
テーブル格納スキーム
テーブルストア（Tablestore）は4つの重要な技術ニーズにおいて完全に要求を満たしています。
その一、フォームは新しい商業化の間もない多元インデックス機能を記憶して、マルチ次元検索、GEOクエリなどの機能をサポートしています。メタデータ管理の需要を完全に満たしています。
その二、LSM treeに基づいて作成された分散式NoSQLデータベースは、海量の高合併に簡単に対応できます。ゼロ運行と維はデータ量の連続的な膨張に容易に対応できます。理論的に上限はありません。
その3、表の保存は量によって課金され、容量型、高性能タイプの2つの実例タイプを提供し、容量型は冷データに対してより適しており、より低い保存コストを提供している。
その4、より重要なのは、フォームの保存はより完璧な計算生態を持ち、全、増分チャネルサービスを提供し、フロー、バッチ一体の計算システムを提供し、未来の監視データ価値発掘にルートを提供する。
テーブルは、タイミングシーンの必要な技術的なポイントに非常に高いマッチングを持ち、タイミングシーンに基づいて作成されたタイミングモデル（Timestream）は、タイミングシーンの汎用機能を使いやすいインターフェースにカプセル化し、ユーザーがより容易にテーブルストレージに基づいてWifi設備のレギュレータシステムを構築することができる。
データ構造設計
まず、私達は表の記憶において、meta類のデータ（デバイスのメタデータ）とdata類のデータ（モニタデータ）という2種類のデータを抽象化しました。二つのデータについて簡単に紹介します。
WiFiデバイスのメタデータ
metaデータはユーザー時間線の属性情報を管理しています。指標、ラベル、属性、地理位置、更新時間などのパラメータをサポートしています。モデルはすべての属性に対してインデックスを作成し、マルチ次元条件の組み合わせクエリ（GEOクエリを含む）を提供します。このうちIdentiferは、タイムラインの識別であり、2つの部分が含まれています。name部分（監視指標標識）、tags部分（固有の可変でないパラメータセット）。
本例では、指標として「wifi」を分類し、macアドレスは可変ではなく、他の属性を可変Attributesとして属性情報として保存します。
デバイスモニタデータ
dataデータは、各時間ラインの監視状態データを管理しており、量子化データ、地理的位置、文字表現のいずれかのタイプであってもよい。dataデータは＋順序で並べられているので、同じ時間ラインのすべてのデータは時間秩序に基づいており、このようなデータ記憶方式は、時間ラインの照会効率を大幅に向上させている。
私達は設備の十数個の監視データのある時点の監視データを一行のデータとして保存します。異なる属性は異なる列に対応します。異なる測定監視次元によって、ユーザーは異なるcolumnToGetフィールドを提供し、異なる監視次元の一部の指標データを取得するだけで、異なる監視指標に対応できます。total_inとwan_total_out 2つのフィールド;
読み書きインターフェース
データを書き込みます
書き込みデータは二つのインターフェースを提供します。Wifiデバイスの追加、モニタデータの書き込み Wifiデバイス追加：Wifiデバイスが追加された場合、まずデバイスmetaデータをmetaテーブルに挿入し、metable.put（Meta）によってmeta情報を作成または修正する必要があります。 監視データの書き込み：metaを作成した後、Wifiデバイス端はタイミング、周期的に監視データを収集し、データをプッシュしてdataテーブルに書き込むことができます。モデル設計は多精度テーブル管理に対応し、ユーザは自身のニーズに応じて複数の精度のデータを管理することができる 。
データを読みます
データを書くのと同じで、2種類のデータに対して2種類の読み取りインターフェースを提供しました。 Wifiデバイスクエリ：デバイスグループ、デバイス状態、地理的位置などの多次元条件の組み合わせに従って、対応Wifiデバイスリストを取得し、デバイスの最新の状態を把握する。 監視データ読み出し：単一のmetaのIdentifeierに基づいて、デバイスのある期間、ある指標の監視データ を取得する。
コアコード
SDKとサンプルコード
SDK：タイミングモデルTimestreamモデルをテーブル格納のSDKに統合し、4.11.0バージョンでサポートしています。
データテーブルの作成
作成したインスタンスの後、ユーザーはタイミングモデルのsdkを通じて、対応するmetaテーブル、dataテーブルを作成する必要があります。様々な精度の監視データを別のテーブルに保存します。名作によって区別されます。様々なレンゲのクエリによって、異なる精度の監視データが必要です。例では、1つの精度だけを使って、ユーザーは自分のニーズに応じて複数のテーブルを設計することができます。
データの書き込みは主に二つの部分に分けられています。meta表には新しいWifi設備、data表採取設備の監視データが追加されます。
新しいWifiデバイスを追加します。（meta表書き込み）
データの読み込みは二つの種類に分けられます。Wifiデバイスのリストクエリとデバイス監視データのクエリです。
Wifiデバイス一覧を照会（metaテーブル読み出し）
会社は監視システムを通じてWifi設備の属性を維持し、Wifi設備の監視データを収集する。Wifiデバイス上、オフラインが必要な場合、レギュレータシステムを通じてデバイスの追加、オフラインが完了し、同時にシステムを介してデバイス属性情報を修正し、追加することができます。設備がオンラインになったら、定期的に監視データをシステムに送って、設備監視データの収集を完成します。収集データには、cpu、メモリ、接続数、Wanポートの流量と流速、2.4 Gと5 Gモジュールのチャネルデータなどが含まれています。
監視データの指標を分析し、設備の運行状態を分析することにより、問題設備の運行状態を注意報、警報に変更する。システムの助けを借りて、ネットワーク部門は問題設備リストを素早く取得し、設備の分布を理解し、履歴監視指標を検索することができます。同時に、古いデバイスを正確にロックし、デバイスのアップグレードを容易にしたり、長期的な負荷率の高い位置にWifiデバイスを拡張するためのデータの根拠を提供したりすることができます。
機能ニーズ
1、Wifi設備を管理し、システムを通じて新設備、オフラインの古い設備をオンラインする。
2、システムはグループ管理能力、ラベル検索能力を持っています。
3、高合併量監視データの収集能力。
4、あらゆる設備の地理的分布を管理する。
5、あるエリア内の全ての設備の位置を調べます。
6、【ある設備】の【ある期間】【異なる指標】における監視データを検索する。
7、低コストの持久化のすべてのデータ、データの潜在価値を掘り起こすなど…。
システムの例は以下の通りです。公式サイトのコンソールアドレス：プロジェクトのサンプル
技術上の需要
通常、ユーザーは設計案において、次の4つの主要な技術ニーズを重点的に考慮することができる。
第一に、強力な照会、統計能力が必要で、Wifi設備の管理を実現する。
第二に、設備の高合併をサポートするモニタリングデータの収集には、データベースの強力な書き込みが必要です。
第三に、データの持続化の需要はデータの膨張を招きますが、履歴監視データは冷媒データが多く、保存コストはできるだけ低い必要があります。第四に、監視データは将来に潜在価値が高く、製品の下流にはより良い計算生態が必要である。
テーブル格納スキーム
テーブルストア（Tablestore）は4つの重要な技術ニーズにおいて完全に要求を満たしています。
その一、フォームは新しい商業化の間もない多元インデックス機能を記憶して、マルチ次元検索、GEOクエリなどの機能をサポートしています。メタデータ管理の需要を完全に満たしています。
その二、LSM treeに基づいて作成された分散式NoSQLデータベースは、海量の高合併に簡単に対応できます。ゼロ運行と維はデータ量の連続的な膨張に容易に対応できます。理論的に上限はありません。
その3、表の保存は量によって課金され、容量型、高性能タイプの2つの実例タイプを提供し、容量型は冷データに対してより適しており、より低い保存コストを提供している。
その4、より重要なのは、フォームの保存はより完璧な計算生態を持ち、全、増分チャネルサービスを提供し、フロー、バッチ一体の計算システムを提供し、未来の監視データ価値発掘にルートを提供する。
テーブルは、タイミングシーンの必要な技術的なポイントに非常に高いマッチングを持ち、タイミングシーンに基づいて作成されたタイミングモデル（Timestream）は、タイミングシーンの汎用機能を使いやすいインターフェースにカプセル化し、ユーザーがより容易にテーブルストレージに基づいてWifi設備のレギュレータシステムを構築することができる。
データ構造設計
まず、私達は表の記憶において、meta類のデータ（デバイスのメタデータ）とdata類のデータ（モニタデータ）という2種類のデータを抽象化しました。二つのデータについて簡単に紹介します。
WiFiデバイスのメタデータ
metaデータはユーザー時間線の属性情報を管理しています。指標、ラベル、属性、地理位置、更新時間などのパラメータをサポートしています。モデルはすべての属性に対してインデックスを作成し、マルチ次元条件の組み合わせクエリ（GEOクエリを含む）を提供します。このうちIdentiferは、タイムラインの識別であり、2つの部分が含まれています。name部分（監視指標標識）、tags部分（固有の可変でないパラメータセット）。
本例では、指標として「wifi」を分類し、macアドレスは可変ではなく、他の属性を可変Attributesとして属性情報として保存します。
デバイスモニタデータ
dataデータは、各時間ラインの監視状態データを管理しており、量子化データ、地理的位置、文字表現のいずれかのタイプであってもよい。dataデータは＋順序で並べられているので、同じ時間ラインのすべてのデータは時間秩序に基づいており、このようなデータ記憶方式は、時間ラインの照会効率を大幅に向上させている。
私達は設備の十数個の監視データのある時点の監視データを一行のデータとして保存します。異なる属性は異なる列に対応します。異なる測定監視次元によって、ユーザーは異なるcolumnToGetフィールドを提供し、異なる監視次元の一部の指標データを取得するだけで、異なる監視指標に対応できます。total_inとwan_total_out 2つのフィールド;
読み書きインターフェース
データを書き込みます
書き込みデータは二つのインターフェースを提供します。Wifiデバイスの追加、モニタデータの書き込み
データを読みます
データを書くのと同じで、2種類のデータに対して2種類の読み取りインターフェースを提供しました。
コアコードSDKとサンプルコード
SDK：タイミングモデルTimestreamモデルをテーブル格納のSDKに統合し、4.11.0バージョンでサポートしています。
<dependency>
<groupId>com.aliyun.openservices</groupId>
<artifactId>tablestore</artifactId>
<version>4.11.0</version>
</dependency>データテーブルの作成
作成したインスタンスの後、ユーザーはタイミングモデルのsdkを通じて、対応するmetaテーブル、dataテーブルを作成する必要があります。様々な精度の監視データを別のテーブルに保存します。名作によって区別されます。様々なレンゲのクエリによって、異なる精度の監視データが必要です。例では、1つの精度だけを使って、ユーザーは自分のニーズに応じて複数のテーブルを設計することができます。
private void init() {
AsyncClient asyncClient = new AsyncClient(endpoint, accessKeyId, accessKeySecret, instance);
TimestreamDBConfiguration conf = new TimestreamDBConfiguration("metaTableName");
TimestreamDBClient db = new TimestreamDBClient(asyncClient, conf);
}
public void createTable() {
db.createMetaTable(Arrays.asList(
new AttributeIndexSchema("group", AttributeIndexSchema.Type.KEYWORD),
new AttributeIndexSchema("id", AttributeIndexSchema.Type.KEYWORD),
new AttributeIndexSchema("status", AttributeIndexSchema.Type.KEYWORD),
new AttributeIndexSchema("version", AttributeIndexSchema.Type.KEYWORD),
new AttributeIndexSchema("location", AttributeIndexSchema.Type.GEO_POINT)
));
db.createDataTable("dataTableName");
}データの書き込みは主に二つの部分に分けられています。meta表には新しいWifi設備、data表採取設備の監視データが追加されます。
新しいWifiデバイスを追加します。（meta表書き込み）
//metaWriter meta ， 、
TimestreamMetaTable metaWriter = db.metaTable();
//identifier （unique）， ：Name、Tags，
TimestreamIdentifier identifier = new TimestreamIdentifier.Builder("wifi")
.addTag("mac", "mock:mac:1:1")
.build();
// identifier meta ， meta ，Attributes
TimestreamMeta meta = new TimestreamMeta(identifier)
.addAttribute("group", "group-1")
.addAttribute("id", "id-1")
.addAttribute("version", "v1.0")
.addAttribute("status", "normal")
.addAttribute("location", "30,120");
// ，
metaWriter.put(meta);
//dataWriter data ， 、
TimestreamDataTable dataWriter = db.dataTable("dataTableName");
TimestreamMeta meta；//meta
// ，
dataWriter.asyncWrite(
meta.getIdentifier(),//Identifier identifier
new Point.Builder(i, TimeUnit.SECONDS)
.addField("cpu", 30)
.addField("ram", 29)
.addField("flash_used", 20)
.addField("flash_total", 1048576)
.build()
);データの読み込みは二つの種類に分けられます。Wifiデバイスのリストクエリとデバイス監視データのクエリです。
Wifiデバイス一覧を照会（metaテーブル読み出し）
//reader meta ， 、 ，
TimestreamMetaTable metaReader = db.metaTable();
//
Filter filter = new AndFilter(Arrays.asList(
Name.equal("wifi"),
Tag.equal("mac", "mock:mac:1:1"),
Attribute.inGeoDistance("location", "30,120", 100000)
));
Iterator<TimestreamMeta> iterator = metaReader
.filter(filter)
.fetchAll();
while (iterator.hasNext()) {
TimestreamMeta meta = iterator.next();//deal with metas
}
//dataWriter data ， 、
TimestreamDataTable dataReader = db.dataTable("dataTableName");
TimestreamMeta meta；// meta ，
Iterator<Point> iterator = reader.get(meta.getIdentifier())
.select("flash_used", "flash_total")//
.timeRange(TimeRange.range(0, Long.MAX_VALUE, TimeUnit.SECONDS))
.fetchAll();
while (iterator.hasNext()) {
Point point = iterator.next();//deal with points
long timestamp = point.getTimestamp(TimeUnit.MILLISECONDS);//
long flashUsed = point.getField("flash_used").asLong();// long
long flashUotal = point.getField("flash_total").asLong();// long
}