サブジェクト領域を記述するための基本エンティティとしてのクインテット

クインテットは、私たちの生活におけるその役割を示す原子のデータを記録する方法です。 クインテットには任意のデータを記述できますが、各クインテットには、自分自身および他のクインテットとの関係に関する包括的な情報が含まれています。 使用されるプラットフォームに関係なく、ドメイン用語を表します。 そのタスクは、データの保存を簡素化し、プレゼンテーションの可視性を向上させることです。







情報を保存および処理する新しいアプローチについて説明し、この新しいパラダイムで開発プラットフォームを作成することについての私の考えを共有します。



クインテットには、タイプ、値、親、兄弟間の順序というプロパティがあります。 識別子を使用すると、5つのコンポーネントのみが判明します。 これは、情報を記録する最も単純で普遍的な形式であり、すべての人に潜在的に適した新しい標準です。 クインテットは、単一構造のファイルシステムの連続した単調なインデックス付き情報フィールドに格納されます。



情報を記録するには、無限の数の標準、アプローチ、ルールがあり、これらの記録を操作するには知識が必要です。 標準は個別に説明されており、データに直接関連するものではありません。 クインテットの場合、それらのいずれかを取得すると、その対象領域での作業の性質、プロパティ、およびルールに関する関連情報を取得できます。 その標準は均一であり、すべての領域で変更されていません。 五重奏団はユーザーから隠されています-メタデータとデータは多くの人にとって馴染みのある形で利用できます。



クインテットは情報だけでなく、実行可能なコマンドでもあります。 しかし何よりも、保存、記録、取得したいデータです。 私たちの場合、それらは直接アドレス指定され、接続され、インデックスが付けられるため、一種のデータベースに保存します。 たとえば、クインテットストレージシステムのプロトタイプをテストするために、通常のリレーショナルデータベースを使用しました。

クインテット構造

この記事の主なアイデアは、マシンの種類を人間の用語に置き換え、変数をオブジェクトに置き換えることです。 コンストラクタ、デストラクタ、インターフェイス、およびガベージコレクタを必要とするオブジェクトではなく、顧客が操作する純粋なクリスタル単位の情報によって。 つまり、顧客が「アプリケーション」と言った場合、この情報の本質をメディアに保存するためにプログラマーの専門知識は必要ありません。







オブジェクトの値のみにユーザーの注意を集中すると便利です。オブジェクトのタイプ、親、順序（従属関係に等しい）および識別子は、コンテキストから明らかであるか、単に非表示になっている必要があります。 これは、 ユーザーがクインテットについて何も知らないことを意味します 。彼は単にタスクを設定し、それが正しく受け入れられることを確認してから、実行を開始します。

基本的な概念

誰もが理解できるデータ型のセットがあります：文字列、数値、ファイル、テキスト、日付など。 このような単純なセットは、問題を定式化し、それとその実装に必要なタイプを「プログラム」するのに十分です。 クインテットで表される基本型は次のようになります。







この場合、クインテットの一部のコンポーネントは使用されず、基本タイプとして使用されます。 これにより、メタデータ内をナビゲートするときにシステムのコアをナビゲートしやすくなります。

背景

ユーザーとプログラマーの間の分析的なギャップにより、問題を設定する段階で概念の大幅な変形が発生します。 控えめな表現、理解不能、および未承諾のイニシアチブは、多くの場合、ユーザーの観点から判断すると、顧客の単純で理解可能な考えを論理的に不可能なミックスに変えます。







知識の伝達は、損失や歪みなしで行われる必要があります。 さらに、将来、この知識のストレージを整理する場合、選択したデータ管理システムによって課せられた制限を取り除く必要があります。

データを保存する方法

原則として、サーバーには多くのデータベースがあり、各データベースにはエンティティ構造の説明と特定の詳細セット（相互接続されたデータ）が含まれています。 それらは特定の順序で保存され、理想的にはサンプリングに最適です。

提案されている情報ストレージシステムは、列、文字列、NoSQLなどのさまざまな既知の方法の妥協案です。 これらの方法のいずれかによって通常実行されるタスクを解決するように設計されています。



たとえば、列ベースの理論は美しく見えます。レコードのすべての行全体ではなく、目的の列のみを読み取ります。 ただし、実際には、データがメディアに配置される可能性は低いため、分析のさまざまなセクションに適用できます。 属性と分析メトリックを追加および削除できることに注意してください。この列の経済を再構築するよりも速い場合があります。 データベース内のデータを調整できることは言うまでもありません。これは、断片化が避けられないため、サンプリング計画の美しさにも違反します。

メタデータ

エンティティ、プロパティ、リクエスト、ファイルなどを操作するオブジェクトを説明する概念-用語-を導入しました。 サブジェクトエリアで使用するすべての用語を定義します。 そして、彼らの助けを借りて、エンティティ間の関係の形を含め、詳細を持つすべてのエンティティについて説明します。 たとえば、props-ステータスディレクトリエントリへのリンク。 この用語は、クインテットのデータで書かれています。



用語の説明のセットは、通常のデータベースのテーブルとフィールドの構造を定義するメタデータです。 たとえば、次のデータ構造があります。コンテンツ（アプリケーションテキスト）とステータスを持つ日付からのアプリケーション。これに、生産プロセスの参加者が日付を示すコメントを追加します。 従来のデータベースコンストラクターでは、次のようになります。







たとえば、バインディングIDなどの重要ではない詳細をすべてユーザーから隠すことにしたため、スキームは多少簡略化されます。IDの記述は削除され、エンティティの名前とそのキー値が結合されます。



ユーザーはタスクを「描画」します：状態（参照値）があり、日付を示すコメントを追加できる今日の日付からのリクエスト：







これで、9の代わりに6つの異なるデータフィールドが表示され、スキーム全体で13の代わりに7ワードを読んで理解できるようになりました。



以下は、この構造を記述するためにコントロールコアによって生成されるクインテットです。







明確にするために、灰色で強調表示されているクインテット値の代わりに説明を提供します。 必要な情報はすべて残りのコンポーネントによって一意に決定されるため、これらのフィールドは入力されません。

ユーザーデータ

上記のタスクのためにそのようなデータセットを保存することを検討してください：







データ自体は、特定の用語のメンバーシップをそのようなセットの形式で示す構造に従って、クインテットに格納されます。







別名隣接リストメソッドによって保存されたよく知られた階層構造が表示されます。

性能

上記の例は非常に単純ですが、構造が数千倍複雑で、データがギガバイトになるとどうなりますか？



必要なもの：

1. 上記の階層構造は1個です。
2. ID、親、およびタイプで検索するためのBツリー-3個。

したがって、データとメタデータの両方を含む、データベース内のすべてのレコードにインデックスが作成されます。 このようなインデックスは、リレーショナルデータベースのプロパティを保持するために必要です。これは最も単純で最も一般的なツールです。 親インデックスは実際には複合です（親ID +タイプ）。 タイプ別のインデックスも、特定のタイプのオブジェクトをすばやく検索するための複合型（タイプ+値）です。



メタデータを使用すると、再帰を取り除くことができます。たとえば、特定のオブジェクトのすべての詳細を検索するために、親IDによるインデックスを使用します。 特定のタイプのオブジェクトを検索する必要がある場合は、タイプIDによるインデックスが使用されます。 タイプは、テーブル名とリレーショナルDBMSのフィールドに類似しています。







いずれの場合でも、データセット全体をスキャンすることはありません。また、あらゆるタイプの値が多数ある場合でも、必要な値は少数のステップで見つけることができます。

開発プラットフォームの基礎

チューリングによれば、そのようなデータベース自体は、アプリケーションプログラミングには十分ではなく、彼らが言うように完全ではありません。 しかし、ここではデータベースだけでなく、すべての側面をカバーしようとしています。オブジェクトは、とりわけ起動可能な任意の制御アルゴリズムであり、機能します。



その結果、複雑なデータベース構造と制御アルゴリズムの別々に保存されたソースコードの代わりに、メディアのボリュームによって制限され、メタデータでマークされた均一な情報フィールドを取得します。 データ自体は、サブジェクト領域の構造とそれに対応するエントリである、わかりやすい形式でユーザーに表示されます。 ユーザーは、構造とデータを任意に変更し、それらを使用して一括操作を行います。

新しいものは何も発明していません。すべてのデータは既にファイルシステムに格納されており、それらの検索は、ファイルシステム、データベースのBツリーを使用して実行されます。 データのプレゼンテーションを再編成したため、データの操作がより簡単で視覚的になりました。

このデータ表現を使用するには、非常にコンパクトなコアが必要です-データベースエンジンはコンピューターBIOSよりも1桁小さいため、ハードウェアでなければ、少なくともできるだけ速く、なめられます。 セキュリティ上の理由から、読み取り専用です。



私の最愛の.Netのアセンブリに新しいクラスを追加すると、このクラスの説明だけのために200〜300 MBのRAMの損失が見られます。 これらのメガバイトは正しいレベルのキャッシュに収まらないため、システムは結果として混乱に陥ります。 Javaでも同様の状況。 クインテットを使用した同じクラスの記述には、数十または数百バイトが必要です。これは、クラスがカーネルに既に馴染みのあるデータを操作するための基本的なトリックのみを使用しているためです。

プログラミングのパラダイム

説明したアプローチの使用は、クインテットだけに限定されず、プログラマが慣れているものとは異なるパラダイムを促進します。 命令型、宣言型、またはオブジェクト言語の代わりに、クエリ言語は人間により馴染みのあるものとして提案されており、プログラマーと既存の開発環境の不可解なレイヤーをバイパスして、タスクをコンピューターに直接設定できます。



もちろん、ほとんどの場合、無料のユーザー言語から明確な要件の言語への翻訳者が依然として必要です。



このトピックについては、例と既存の開発を含む個別の記事で詳しく説明します。



したがって、要するに、次のように機能します。

1. かつて、クインテットのプリミティブデータ型（文字列、数値、ファイル、テキストなど）で説明し、カーネルがそれらを操作できるようにトレーニングしました。 トレーニングは、データの正しい表示とそれらを使用した簡単な操作の実装に限定されます。
2. 次に、メタデータの形式で、クインテットユーザー用語（データ型）で説明します。 説明は、ユーザータイプごとにプリミティブデータタイプを指定し、従属を決定することになります。
3. メタデータで指定された構造に従ってデータクインテットを入力します。 データの各クインテットには、そのタイプと親へのリンクが含まれているため、データウェアハウスですばやく見つけることができます。
4. コアタスクは、データを取得して簡単な操作を実行し、ユーザーが記述した任意の複雑なアルゴリズムを実装することです。
5. ユーザーは、最初と2番目の両方を視覚的に表示する視覚的なインターフェイスを使用して、データとアルゴリズムを管理します。

システム全体のチューリング完全性は、基本要件の実施形態によって保証されます。カーネルは、シーケンシャル操作を実行し、条件分岐し、データセットを処理し、特定の結果が達成されたときに作業を停止できます。



人にとっての利点は、たとえば、変数を含むサイクルを宣言する代わりに、知覚が簡単になることです

for (i=0; i<length(A); i++) if A[i] meets a condition do something with A[i]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より理解しやすい設計が使用されます

 with every A, that match a condition, do something
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ループ、デザイナー、関数、マニフェスト、ライブラリなど、情報システムの実装の低レベルの微妙さから抽象化することを夢見ています。これらはすべて、プログラマの脳内のスペースを取りすぎ、創造的な仕事と開発のためのスペースをほとんど残しません。

スケーリング

最新のアプリケーションは、スケーリング手段なしでは考えられません。情報システムの負荷容量を拡張する無制限の能力が必要です。 説明したアプローチでは、データ編成の極端な単純さを考慮して、既存のアーキテクチャーほど複雑ではないスケーリングが行われます。



アプリケーションを使用した上記の例では、たとえばIDでアプリケーションを分離し、異なるサーバーの固定高バイトを持つIDを生成できます。 つまり、IDの保存に32ビットを使用する場合、必要に応じて最上位の2〜3〜4ビット以上が、これらのアプリケーションが保存されているサーバーを示します。 したがって、各サーバーには独自のIDプールがあります。



単一のサーバーのコアは、他のサーバーについて何も知らなくても独立して機能できます。 アプリケーションを作成すると、使用されるIDの数が最小のサーバーに高い優先度が与えられ、均一な負荷分散が保証されます。



単一のデータ組織内のリクエストとレスポンスのバリエーションが限られているため、サーバー間でリクエストを分散し、結果を集計するかなりコンパクトなディスパッチャが必要になります。