娯楽 | フォーラム

最近

+

新規投稿

証明付き投稿

解決規則

方法 / 原理どう？

[結果]「あのような物事はうまくいく方法を見つけました…」

もっと見る..

+
企画規則

仕事 / 活動なに？

[結果]「今度はれこを行いました、次にあれを行います…」

もっと見る..

動き

o-92001

14 ᵈ週 9 日前に I implemented column hashing @ Postgres synchronization solution

以前のデータと現在の列、および以前のハッシュを取得してデータベース全体のハッシュを生成するハッシュを実装しました。

これにより、すべてのデータを再ハッシュし、ソートされたデータのバイナリ検索のハッシュを取得するシンクロナイザー部分を作成するときに、最小限のデータ送信で同期することができます。

- 元の言語で表示 -

I implemented a hash that takes previous data and current column and the previous hash to produce a hash of the entire database.

This allows us to synchronize with the minimum of data transmissions when I write the synchronizer part which shall rehash all its own data, then retrieve the hash of a binary search of the sorted data.

—chronological

-3.0000 ħ (3.0 HUR) (+0.0)

o-91001

15 ᵈ週 89 ᵈ分前に I implemented document storage in my database project @ Document database backed by keyvalue storage

この問題の残りの部分に数時間を費やし、ドキュメントの保存が完了した後、ドキュメントの取得が機能するようになりました。

これにより、JSON ドキュメントを保存および取得できます

挿入されたドキュメントデータは、SQL でクエリすることもできます。

ドキュメントに対する結合はまだサポートされていませんが、これを実装する予定です。

- 元の言語で表示 -

I spent a few hours working on the remainder of this problem and got documnent retrieval working after finishing save document.

This lets you save and retrieve JSON documents

The document data inserted is also queryable by SQL.

Joins against documents are not yet supported but I plan to implement this.

—chronological

-4.0000 ħ (4.0 HUR) (+0.0)

15 ᵈ週 9 日前に For 100 threads I managed to get 100 million multithread communication event requests a second, taking 10 nanoseconds to communicate between threads @ Parallel multithreaded actors without locks

ほとんどのコンピューターは同期にロックを使用しますが、これは非常に低速です。この設計ははるかに高速であり、ロックを省略してパフォーマンスを向上させることができます。

私は非同期データ構造を使用し、1 バッチのメッセージあたり 10 ナノ秒のコストで、1 秒あたり 1 億回のリクエストを生の通信パフォーマンスで達成しています。

- 元の言語で表示 -

Most computers use locks to synchronize, which are very slow. This design is far faster and allows locks to be elided for performance.

I use unscynchronized data structures and achieve 100 million requests a second raw communication performance for a cost of 10 nanoseconds per batch of messages.

—chronological

-8.0000 ħ (8.0 HUR) (+0.0)

16 ᵈ週 3 ᵈ時前に Saving JSON documents as SQL @ Document database backed by keyvalue storage

JSON ドキュメントを保存し、SQL インサータを使用してドキュメントを挿入しました。理論的には、オブジェクトは SQL でクエリ可能です

{

"アイテム": [("名前": "アイテム1"), ("名前": "アイテム2")],

"subobject": {"subobject_key": "value"} }

- 元の言語で表示 -

I managed to store a JSON document and I used the SQL inserter to insert the document. In theory the object is queryable by SQL

{ "items": [("name": "item1"), ("name": "item2")], "subobject": {"subobject_key": "value"} }

—chronological

-3.0000 ħ (3.0 HUR) (+0.0)

16 ᵈ週 9 日前に I updated epollserver to multiplex client sockets across threads. @ Efficient multithreaded server

各スレッドにはリングバッファがあり、ソケットが受け入れられるとメッセージがリングバッファに置かれ、スレッドはそのユーザーのリッスンを開始します。

他のすべてのスレッドにはすべてのユーザーが通知されるため、データをエコーすることもできます。

スレッドは数千万の接続に対応でき、複数のスレッドがあるため、これは効率的です。

マルチスレッドの一般的な問題の 1 つは、1 つのスレッドから複数の種類のイベントの 1 つを処理することです。私はリングバッファと epoll をポーリングしているという事実に依存しています。

- 元の言語で表示 -

The idea is that each thread has a ringbuffer, when a socket is accepted, a message is put on the ringbuffer and the thread begins listening to that user.

All the other threads are notified of all the users so they can also echo data to them.

This is efficient as a thread can serve thousands-millions of connections and there are multiple threads.

One problem, which is a generic problem for multithreading is servicing one of multiple kinds of events from one thread. I rely on the fact I am polling a ringbuffer and epoll.

—chronological

-7.0000 ħ (7.0 HUR) (+0.0)