私があなたの考えを正しく理解しているなら、あなたは時系列をPostgreSQLに保存することを検討しています。1つの時系列レコードを1つのデータベース行に保存します。そうしないでください。
一方では、問題は理論的です。リレーショナルデータベース（およびほとんどのデータベース）は行の独立性を前提としていますが、時系列のレコードは物理的に順序付けられています。もちろん、データベースインデックスは、データベーステーブルに一定の順序を提供しますが、その順序は、検索を高速化したり、結果をアルファベット順またはその他の順序で表示したりすることを目的としています。それはその順序に自然な意味を意味するものではありません。注文方法に関係なく、各顧客は他の顧客から独立しており、顧客の購入履歴を形成するために時系列でまとめて入手できたとしても、各顧客の購入は他の顧客から独立しています。時系列レコードの相互依存性ははるかに強力であるため、リレーショナルデータベースは不適切です。
実際には、これは、テーブルとそのインデックスによって占有されるディスクスペースが巨大になり（おそらく時系列をファイルに格納するよりも20倍大きくなる）、データベースからの時系列の読み取りが非常に遅くなることを意味します。ファイルに保存するよりも桁違いに遅くなります。また、重要なメリットはありません。 「値がXより大きいすべての時系列レコードを教えてください」というクエリを作成することはおそらくないでしょう。このようなクエリが必要になった場合は、リレーショナルデータベースが実行するように設計されていない他の分析も必要になるため、とにかく時系列全体を何らかのオブジェクトに読み込むことになります。
したがって、各時系列はファイルとして保存する必要があります。ファイルシステム上のファイルか、データベース内のBLOBのいずれかである可能性があります。後者を実装したという事実にもかかわらず、前者の方が優れていると思います。 Djangoでは、次のように書きます：
class Timeseries(models.model):
name = models.CharField(max_length=50)
time_step = models.ForeignKey(...)
other_metadata = models.Whatever(...)
data = models.FileField(...)
FileFieldの使用 データベースが小さくなり、システムの増分バックアップを簡単に作成できるようになります。また、ファイルを検索することでスライスを取得するのも簡単になります。これは、ブロブではおそらく不可能または困難なことです。
さて、どんなファイル？パンダを見てみることをお勧めします。これは、時系列をサポートする数学的分析用のPythonライブラリであり、時系列をファイルに保存する方法も必要です。
上記で、使用をお勧めしない私のライブラリにリンクしました。一方では、それはあなたが望むことをしません（それは1分より細かい粒度を処理することができず、他の欠点があります）、そして他方ではそれは時代遅れです-私はパンダの前にそれを書きました、そして私はそれを変換するつもりです将来的にパンダを使用します。パンダの作者による「データ分析のためのPython」という本がありますが、これは非常に貴重だと思います。
更新（2016年）： InfluxDBもあります。一度も使ったことがないので意見はありませんが、時系列の保存方法がわからない場合は必ず検討する必要があります。
更新（2020-02-07）： PostgreSQLの拡張機能であるTimescaleDBもあります。
更新（2020-08-07）： TimescaleDBを使用してデータベースにデータを保存するように、ソフトウェアを（再度）変更しました。私たちはすでにPostgreSQLに精通しており、TimescaleDBを学ぶのは簡単でした。最も重要な具体的な利点は、「2019年の24時間以内に50mmを超える雨が降った場所をすべて見つける」などのクエリを実行できることです。これは、フラットファイルにデータを保存する場合には非常に困難です。もう1つの利点は、整合性チェックです。何年にもわたって、あちこちに小さなバグがあるため、行が重複する時系列がいくつかありました。欠点も重要です。 10倍のディスク容量を使用します。そのため、PostgreSQLのバックアップポリシーを変更する必要があるかもしれません。遅いです。 300kレコードの時系列を取得するには、おそらく1秒かかります。これは前の瞬間でした。以前は必要なかった時系列を取得するためのキャッシュを実装する必要がありました。