2017-09-12 4 views
0

は、以下のJSON構造を考える:一意の識別子である(例えば'100''101'、等)JSON階層符号化及びイベント捕捉

{'100': {'Time': '02:00:00', 'Group': 'A', 'Similar events': [101, 102, 104, 120], 
'101': {'Time': '02:01:00', 'Group': 'B', 'Similar events': [100, 103, 105, 111], 
'102': {'Time': '04:00:00', 'Group': 'A', 'Similar events': [104, 100, 107, 121]} 

トップレベルの鍵。私はこれがではないことがわかった。 JSONを格納する理想的な方法(この構造を読み込もうとする - より多くのイベントがある - 私のPCがクラッシュする)。

いくつかの掘削後、私は、これはJSONでこれらのデータを符号化する適切な方法(あるいは、少なくとも、はるかに標準的な方法)であると考えている:

{'Time': [{'100': '02:00:00'}, 
      {'101': '02:01:00'}, 
      {'102': '04:00:00'}], 

'Group': [{'100': 'A'}, 
      {'101': 'B'}, 
      {'102': 'A'}], 

'Similar events': [{'100': [101, 102, 104, 120]}, 
        {'101': [100, 103, 105, 111]}, 
        {'102': [104, 100, 107, 121]}]} 

私のマシンは、このはるかに良いを処理することができます最後の試行。私の個人的な "行"としてユニークなイベントを使用していた私の以前の方法は、どうして大きな問題になるのでしょうか?私の腸は、以前の試行の各レコード内の各「列」またはキーは、一意の識別子(一意のキー)の下にあるため新しいフィールドになります。

答えて

0

データの合計サイズ、コンピュータのメモリ容量、使用しているソフトウェア、実行しようとしている特定の操作などの詳細がなければ、言うことは難しいですが、 2番目の表現のワーキングセットは問題の方が小さくなります。

+0

データのサイズは問題ではないとは思いません。この問題は前者のアプローチと、トップレベルのIDの記憶メカニズムのために、どのようにして* n * * * k *の異なるフィールドを効果的に作り出すかと関係していると思います。あなたが私に従えば、* k *(* k *はキャプチャするユニークなフィールドの数です)ではなく、CSVの* n * * * k *カラムを作成するようなものです。 – blacksite

+0

@blacksite 2番目の方法は、同じ量のフィールドを列よりも多くの行だけです。これは本質的な問題ではなく、この2つのアプローチのいずれかが他のアプローチよりも適切なものになることはありません。後であなたのために働く場合は、それを使用する特定の方法のためです。 – Oleg

+0

@Oleg私はこれらのデータをTableauにロードしようとしています。そして、Tableauが最初のアプローチを扱う方法は、その多くの異なる列を作成することです...私は現在、このようなものを中間の一種のスタースキーマに変換しています。私はこれを理解する。 – blacksite

関連する問題