Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源は多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています GitHub
漢字画数データベースについて 本データベースは、UCSのBMP/Ext-B/Ext-Cの全統合漢字データに対し、可能な限り正確な画数のデータベースを提供します。 Unihan.txt の"kTotalStrokes" 情報は、康煕字典の数え方を主体としつつ、 一部に簡体字風な画数の数え方が混じるなど一貫性に欠け、多数の誤りがあり、 また拡張漢字B, Cの画数情報は提供されていません。 本データベースは、これらの問題を解決し、IDSと組合せた漢字の検索に対して十分な実用性を提供できることを目指して開発されました。 本データは UCS の BMP/Ext-B/Ext-Cの全統合漢字に対し、可能な限り正確な画数データを提供します。 本データは、３部首（艹・礻・辶）のように、複数の画数の数え方がある漢字部品に対しては、 「必ず」複数の画数を与えるようにしています。 そのため、たとえば「草冠＋４画」
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
