クラウド共有ストレージ形式

リモートオフィスは30人で構成されています。 この仕事は、米国のSEOのみに関連しています。 そして、これは昼と夜を想定しています-労働者はさまざまなタイムゾーンに散在しているため、数百のリンク、連絡先、特性を検索して見つけます。 情報は雪崩のような方法で収集され、1日では、テーブルは1200から3000セル分拡張されます。 これに半年の仕事を掛けて...すでに今日、私の頭が回転しています。

大量のデータを扱うこの種の仮想会社は、特定の段階でそのストレージのフォーマットを変更することを考えていると思います。 この記事では、主題で説明されている問題に触れ、資料の最後に出された質問について解説者と話し合いたいと思います。 詳細が不足していることをあらかじめおaび申し上げます。一般的な議論にすべての美味しさをもたらすことはできません。

Microsoft Excel

1年半前にフラッシュバックを作成しましょう。 絶対にすべての責任を負う1人（この場合はI）がチームを率いている場合、彼はMicrosoft Excelを使用してすべての「富」を簡単に管理できます。 リンク、メールアドレス、電話番号、その他の情報にかかわらず、古き良きExcelは、開発に問題がないように設計されています。 最初に手が間違った場所で成長した場合、それは大丈夫です-時間が経つにつれて、すべての重要な機能が必要に応じて習得されます。
最初は、あるタブから別のタブにセルをコピーすることはそれほど難しくありませんでした。 この「サル労働」は緊張せず、ある程度まで持ち去られました。 すべてのデータは、タブに分割された単一のファイルに収まります。 アーカイブ目的で蓄積および保存された情報（つまり、アクティブなアクセスが想定されていなかった情報）は、追加のファイルに転送されました。 庭には2010年がありました。

Googleドキュメント

1年間でデータ量がどのように増加したかを見てみましょう。

1タブ（.xls、Excel）=> 10タブ（.xls、Excel）=> 5ファイル（.xls、Excel）

その結果、3つのファイルが形成されましたが、その合計量は10万個のセルを超えませんでした。
仕事が耐えられなくなったとき、彼らは仮想オフィスを建設することを決めました。予想通り、誰もが自分の仕事の範囲を実行します。
2011年が来ました...すぐにドキュメントの同時編集を提供するために、すべてのデータベースをGoogleドキュメントに転送することが決定されました。 オンラインプラットフォームに切り替える主な動機はあまりありません。 しかし、あなたは見る、彼らは他のすべてを上回る：

• 一緒に働く能力
• ストレージの信頼性
• 無料

Googleドキュメントに代わる別のオンラインの選択肢を見つけることはできましたが、必ずしも必要ではありませんでした。 優れたものはありませんでした。 ここでは、代替の無料サービスに影を落とさないように、テストしたすべての可能なオプションについては説明しません。 結論は1つだけです：それらの多くはなく、それらはすべて機能的にGoogleドキュメントの背後にあります。 誰かが同意しない場合は、コメントに書いてください。 著者が間違っている可能性があります。
しかし、軟膏のハエが見つかりましたが、ハエは1つではなく、スクープ全体が見つかりました。 非常に迅速に、Google DocsはExcelに関する欠点を明らかにし始めました。 私たちが積極的に作業したドキュメントは次第に増えていき、そのうち約10がありました。毎日500〜1000行ずつドキュメントが補充されていましたが、塗りつぶされたセルの数を取得するには2倍する必要があります。 そして、Googleドキュメントの限界が感じられました。 40万 細胞、紳士、これ以上。

残念ながら、これはすべての不便さではありません。 他に何？

• 必要なオプションはあまりありません（重複を削除するため、セル内のテキストの一部を選択することはできません。
• Excelと比較して、セルのコピーと1つのドキュメントから別のドキュメントへの切り替えの速度は2倍低下しました。
• インターネット中毒（文字通り）およびトラフィック消費。 インターネットなし-データへのアクセスなし。
• URLを扱うため、ハイパーリンクからドキュメントを削除する必要があります。

根拠のないように、私は同僚にフロアを渡します。 彼らが不満を言うのは次のとおりです。
アーサー：
迷惑な制限の400,000セル
ブレーキ、今日では一般的にドックを使用することは不可能で、ロードしません
パシャ：
ええ、私もくさびをしています。 ドックに1000個を超えるリンクを追加できない
イゴール：
ドックでは、ラグとエロラは常に恥ずかしくて迷惑です！ +一度に1000個を超えるセルを転送しないでください。
オルガ：
現時点では、Googleドキュメントは不便です。
1.ドックからドックへの転送-削除する必要があります。タブでのみ転送されます。
2.検索時に、1つのドキュメントで見つからない場合、または安全上の理由で、3〜4つのドキュメントを交互に検索する必要があります。 SQLへの移行により、すべてのデータを1つのデータベースに結合できる場合、これにより検索が高速化され、重複を回避できます!!!

さて、13時以降、Google Docksは単に動作を拒否しました。 ラダ： 「一度に1000個を超えるセルを転送しないでください。」 昨日、6個のセルを転送することさえできませんでした）デザートの場合-2つの通常の問題：
そして時間...

そして2つ...

何に来たのか、中年の危機

5ファイル（.xls、Excel）=> 20個のGoogleドキュメントファイル=> ??? :(

2011年、6月。 テーブルにデータを保存することはますます難しくなっています。 さらに、Googleドキュメントの制限が厳しくなりました。新しいドキュメントを作成する必要があり、メールを扱う人はドック間をジャンプする必要があります。 昨日、2日連続で、個々の従業員はまったく天国に着くことができませんでした。
ドキュメントを小さなドキュメントに分割することは最良の解決策ではありません。複数のドキュメントを開き、それぞれで必要な情報を探す必要があります。 そして、重複がある場合はどうなりますか？ 各リンクを2回確認することはできません。

オリヤ：
私は現在、「control mail」、「control」というファイルを介して各リンクを実行しています。 確認のためにmail2”および” second run”、場合によっては” calling and letters”によって、一般に、1つの結合文書を数秒で検索する代わりに、数分かかります。
理想的には、ドキュメント内の1つの手動検索要求（URL、メール）が10秒かかることを想像してください（これは、検索ウィンドウが定期的に開かれるという事実を考慮しています）。 これは、検索に進む前に彼が背中とあくびをすることも考慮に入れていません。
1日あたり10分の節約でも、1か月あたり4時間の節約になります（10分に22営業日を掛けます）。 さらに10（Googleドキュメントで検索をアクティブに使用している従業員数）を掛けると、それらの秒数を節約せずに、40労働時間が煙突から飛び出します。 実際、私たちとの支払いは1時間ごとです。

どこへ行くの？

上記のすべてが、すべての情報について、ファイルではなくカテゴリに分類された単一のデータベースを必要とするという考えにつながります。 どういう意味ですか？ カテゴリの変更は、次のようなジェスチャーではなく、2回のクリックで行う必要があります：セルをコピーする（目的の領域に初めてアクセスする）、別のドキュメントに貼り付ける、古いドキュメントから削除する。 はい、Google Docsが同じブック内でのみ、あるタブから別のタブに情報をカットすることを学習するまで。 そして、ハイパーリンクの愚かなアクティベーションは、アクティブなURLからドキュメントを定期的に削除することを強制します。 一般的に、どんな些細なことでも腹立たしくなります。 または、別の例を示します。

ExelおよびGDocsエンティティのテーブルを破棄する必要があります。

上司に、ExcelやGoogleドキュメントではなく、SQLでのデータの保存を開始することを長い間提案してきました。 これで、さまざまなデータを含む数万行になりました。 これらはすべて、日付、URL、コメントなどの単一の形式に多少削減されます。したがって、蓄積したすべてを単一のSQLデータベースに無制限に転送できます。
しかし、問題は何ですか？ SQLをデータベースの形式でメモ帳で開くことはできません。手動で編集を開始することはできません。 一方で、データベースを習得することは難しくなりますが、他方では、データストレージをシンプルでアクセスしやすくする方法は難しくなります。 さらに、ニーズに合わせて「人間の」シェル、UI、「シャープ」が必要です。 実際、ここに私たちの要件があります：

1. 検索により、ブラックリスト（ブラックリスト）のリンクの存在からレポート（ホワイトリスト）のリンクまで、必要なすべてのものを見つけることができます。 これにより、クライアントに手紙を再送信したり、重複したりする可能性が低くなります。 検索フィルターを使用して、指定された基準に従ってデータベース内のリンクをフィルターで除外できます。
2. 列では、必要なものをすべて指定できます。行は全画面表示されません。 ワーカーは、SQL形式でデータをエクスポート/インポートできます。
3. 表の行には「刻み込み」が付けられます。それは、イヴァノフが（非）快感を伴う情報を見つけたという記録を含みます。 したがって、各リンクの運命を追跡できます。
4. Cronスケジューラの助けを借りた管理。スケジュール上のリンクを使用して、必要なことを何でも行うことができます。PRとExtを再確認します。 リンク。 実際、Google Docsスクリプトは必要ありません。
5. SQLには、Googleドキュメントのような制限はありません。 基盤は私たちにとって一生に十分です。
6. 数回のクリックで便利なバックアップ。
7. あるインスタンスから別のインスタンスに行を転送するために、ファイル間をジャンプする必要はありません。 リンクのカテゴリを変更します（チェックボックスを使用できます）-これで完了です。 例？ リンクの作業を行いました-カテゴリを「XXX」に変更しました。 ダイヤラはカテゴリXXXを開きます（カテゴリのリストが表示されます）。 リンクが不要になった場合は、カテゴリをブラックリストに変更してメモを編集します。 などなど。
8. 高速インポート/エクスポート。 たとえば、アイコンをクリックするだけで、必要なパラメーターでデータを並べ替え、マウスを数回クリックするだけで、テーブルをCSVにエクスポートできます。

もちろん、これはすべての要件ではありませんが、現在、同じGoogleドキュメントでは非常に不足しています。
おそらく、SQLデータベースはCMS Drupalの下で実行できます。 なぜDrupal 彼女のために、私たちのニーズに適用できる一定数のモジュールが書かれています（少なくともそれらのいくつかは、残りは後で書かれます）。 このCMSには、ロシア語話者を含む大規模なコミュニティがあります。 負荷およびその他のバンのスケーラビリティが付加されます。

しかし、ここに問題があります。 新しい自転車を発明したくありません。 それでも、決定は大規模オフィス全体の生産性に根本的に影響します。 すべてのデータをDrupalに転送した後、後からすべてを転送して頭に灰を振りかける必要がないのはどうしてでしょうか。 それから彼らは私がそのような解決策を提案した長くて痛い事実のために私を個々に罰するでしょう。 上司と部下の両方。
だから、 専門家の助けが必要です。 議論のために以下の質問を提案します。

• 1000万セル以上の領域で、大量の情報を保存するのに最適なDBMSはどれですか。 MySQL？ オラクル？！
• Drupalによるデータベース管理-それはどれほど効果的ですか？
• 比較的小さな会社では、データベースに加えてどのようなソリューションを使用できますか？
• Drupalプログラマーを継続的に維持することは理にかなっていますか？ 最初は、SQLのデータの一部のみを移動し、レポートなどのGDocsに何かを保存できます。

アドバイスをお願いします。