以前の記事で、ベクトルデータベースのPineconeを紹介しました。そろそろ他のベクトルデータベースも試してみたいと思い、今回はWeaviateについて調べてみました。「ベクトルデータベースとは」というところについては、以前の記事で触れていますので参照してください。 Weaviateの概要 Weaviateは、オープンソースでAI Nativeのベクトルデータベースです。「AI Native」というところが特徴で、MLモデルをモジュールとして組み込むことができ、それによってデータベースの内部でオブジェクトのベクトル化を行ったり、分類をしたり、結果を言語生成して返すなど様々なユースケースに対応できます。 主な特徴は以下のとおりです。(What is Weaviate? より意訳してます) オープンソースです。 データオブジェクトをベクターでインデックス化することで、そのセマンティックな特性に
今回答えを出したい問いはこちら!! インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ!!!!それじゃいってみよー🎉 あと、おれは今回MySQLにしぼっていくぜ👶 ってわけでOracleとかに興味があるやつは引き返しな! indexの概要 公式の見解としては「where句を使ったselectクエリの実行速度を向上させるために実装されている、各行へのポインターのような振る舞いをする仕組み」って感じ👶 The best way to improve the performance of SELECT operations is to create indexes on one or more of t
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性(ACID)というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが(クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている)、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
Jack Wallen (Special to ZDNET.com) 翻訳校正: 編集部 2024-04-10 07:30 「Linux」は長年にわたりクラウド上のサーバーに搭載されてきたが、クラウドが急激に拡大したこと、そしてLinuxがクラウド専用に設計されたものではないことを考慮すると、何かを変える必要があることは明らかだった。 その変化をもたらすのは、「Ingres」「PostgreSQL」「VoltDB」の開発に携わったMichael Stonebraker氏と、「Apache Spark」の生みの親でDatabriskの共同創設者/最高技術責任者(CTO)であるMatei Zaharia氏かもしれない。両氏はマサチューセッツ工科大学(MIT)のチームと協力して、「DBOS」(別名「DataBase OS」)という革新的なOSを開発した。 DBOSの開発は2022年に始まった。D
今、自分が所属している会社では、いわゆるフルサイクルなアプリケーションエンジニアがほとんどで、SRE のような、システムを運用改善することを専門にするメンバーは居ません。一方でそれなりにプロダクトの数は多く、各種ミドルウェアの運用で困っているのを見かけることがあります。 色々な人が似た問題に悩むのはもったいないので、「MySQL を運用したことがある人からすると、こういう考え方をする」という風な目線で勉強会を行いました。せっかくなので社内の情報を抜いたうえで公開します(同じようなことを色々な場所で言っていて、その都度作り直しているから……というのもあります)。 speakerdeck.com ちなみに DB のどこで悩むかはだいぶ業界ドメインに左右されると思っています(それはそう)。ゲーム業界なんかは、激しくスパイクするワークロードな上にミスったときの機会損失が激しいので、シャーディングを
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS(いわゆるリレーショナルデータベース)というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
はじめに 以前こんなツイートをしました。 すると、リプライで色々とコメントを頂きました。(疑問を投げかけたら答えてくれる方々、本当にいつもありがたいです🙇♂️) ということで、本記事では推定行数と実際の行数の乖離を減らすために何をやったのかを備忘として書きます。 ただ、実際のSQLや実行計画を書くことはできないので、あくまでどんな考え方をしたのか、ということを書きます。 対処法①(対象のテーブルのautovacuum頻度を変更) 対象のテーブルはかなり更新の激しいテーブルだと聞いていたので、まずは統計情報が最新化されているかを考えました。 更新が激しくてautovacuum時の自動ANALYZEが追い付いていないんじゃないかと考え、対象のテーブルだけ自動ANALYZEの頻度が上がるように設定を変更しました。 PostgreSQLの設定パラメータは基本的にはpostgresql.conf
はじめに こんにちは、令和トラベルでバックエンドエンジニアをしている飯沼です。 MySQLでは、UUID (v4)などのランダム性の高いIDをプライマリキーに設定すると、パフォーマンスが低下すると言われています。私自身もこの問題については認識しておりアンチパターンとして避けて来ましたが、イマイチ理由を理解できず何度も調べていたので自分の理解を整理しました。 ※ この記事は令和トラベルのTech LT会で共有した内容を記事にしたものです。社外の方にもご参加いただけるTech LT会は connpass にて告知しています。 UUIDをプライマリキーにするユースケース そもそもUUIDをプライマリキーにするユースケースはどのようなものがあるのでしょうか? いくつかの観点から考えてみます。 パフォーマンス観点 大量の同時書き込みが発生するような状況でauto incrementを利用してIDを発
データベースシステムに関する入門。データベースの基本概念、データモデリング、リレーショナルデータモデル、データベース言語SQL、リレーショナルデータベース設計論、物理的データ格納法、問合せ処理等について講述する。 (2018年度) 【教科書】 「データベースシステム」(北川博之著、オーム社) 北川 博之筑波大学 計算科学研究センター教授1978年東京大学理学部物理学科卒業。1980年同大学理学系研究科修士課程修了。日本電気(株)勤務の後、筑波大学電子・情報工学系講師、同助教授を経て、現在、筑波大学計算科学研究センター教授。理学博士(東京大学)。データベース、データ統合、データマイニング、ストリーム処理、情報検索、ビッグデータ等の研究に従事。著書「データベースシステム」(オーム社)等。日本データベース学会会長、ACM SIGMOD日本支部委員長等を歴任。情報処理学会フェロー、電子情報通信学会
Connection Management: WeScale efficiently manages connections to your database, reducing the overhead on your application and improving performance. WeScale relieves you of the worry of the max_connection problem in your database. Read Write Split: WeScale simplify application logic by automatically routing read queries to read-only nodes and write queries to the primary node. This is achieved by
この記事は DeNA 24 新卒 Advent Calendar 2023 の 23 日目の記事です。 TL;DR DBMSの基本的な仕組みを知るのに有益だったリソース CMUのDBMS講義 先人の素晴らしい自作DBMSの解説記事&ソースコードリーディング 小さな小さな自作DBMSの設計と実装 最小限SELECTやINSERTなど基本的なSQLが動く この記事のゴール データベースの内部構成を超ざっくり理解するために有用なリソースを知り、そして(全開発者のロマンである)自作 DBMS に一歩踏み出すきっかけになればうれしいです。 モチベーション 自分は普段業務でアプリケーションのような割と高レイヤーな開発がメインなこともあって、ミドルウェアやOS、ネットワークと言った低めのレイヤーに憧れを持っており、この気持ちをまずは自作DBMSをやってみることによって解放してあげようと思ったことがきっか
これは はてなエンジニアアドベントカレンダー2023 3日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita 昨日は id:pokutuna さんの blog.pokutuna.com でした。私も若い頃に同僚とGitHub上で白熱してしまい観光名所になってしまっていたような気がします。気を付けていきましょう。 さて、この記事では SQLiteでLinderaを使った日本語全文検索をする話を紹介します。 モチベーション laiso.hatenablog.com 上の記事でも話題になっているように個人開発ではDBのコストは問題です。同様に全文検索したいときにもコストに頭を悩ませているのではないでしょうか? たとえば Amazon
こんにちは。バクラク事業部 Enabling チームの @izumin5210 です。最近「HUNTER×HUNTER」の既刊を全部読みました。 この記事はLayerXテックアドカレ2023の9日目の記事です。 前回「1人目データアナリストとしてデータチームに異動しました 」 次回「Slack × Zapier × MiroでKPTでの振り返りをラクにする」 RDB や KVS などのデータ保存先において、データを正規化せずにそのまま保存したいと思うことはありませんか? 8月にリリースされた「バクラク請求書発行」というプロダクトには「柔軟なレイアウトカスタマイズ」機能が搭載されています。リンク先の画面操作イメージを見ていただくと、この機能の雰囲気を理解していただけると思います。この機能が扱うレイアウトデータはまさに「関係の正規化をせずに保存したいデータ」でした。 bakuraku.jp こ
ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は?[PR] 日常的に多数の同時アクセスが発生し、大量のデータが蓄積されるオンラインゲームのバックエンドは、データベースにとってもっとも過酷な環境の1つだといえます。 このバックエンドデータベースとしてよく使われているのがMySQLデータベースです。しかしその使われ方は一般的なMySQLとは異なり、データベースを細かく分割して多数のサーバに負荷を分散するシャーディングと呼ばれる仕組みを構築するなど、複雑なシステム構築と運用が行われているのが現実です。 そこで急速に注目度を高めているのが、MySQL互換でありつつ分散データベースの機能を備え、シンプルなクラスタ構成で高い負荷に耐える、いわゆる「NewSQL」と呼ばれる分野の代表的なデータベースの1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く