# Weaviateの機能と実践的な使い方 🚀 「テストのためにベクトルDBサーバを立てるのが面倒」を解決するのがEmbedded Weaviateです。スクリプトから一行で起動し、終われば消える使い捨てDBとして、CIやノートブックに組み込めます。 📌 タイトルと機能のURL タイトル: Embedded Weaviate URL: 📝 概要 Embedded Weaviateは、独立したサーバを立てる代わりに、アプリケーションのコードからWeaviateインスタンスを起動する実験的なデプロイ方式です。インスタンスのライフサイクルはクライアントアプリに紐づき、アプリが終了するとインスタンスも終了します(ただし永続化したデータは残ります)。インフラ準備ゼロで実験を回せるのが最大の利点です。 🔧 機能の説明 ・Pythonでは weaviate.connect_to_embedded(version=..., headers=..., environment_variables=...) でインスタンスを起動します。 ・クライアントは binary_path のキャッシュにバイナリがあるか確認し、無ければGitHubリリースから適切なバイナリ(linux/macOS向け)をダウンロードしてキャッシュします。 ・初回起動時に persistence_data_path に永続データストアが作られ、次回以降は同じデータストアを再利用するため、セッション間でデータが残ります。 ・ライフサイクルはスクリプト終了・アプリ終了・ノートブックの非アクティブ化で終了します。 🛠 実践的な使い方 ・主なパラメータは version(latest・バージョン文字列・バイナリURL)、port(既定8079)、persistence_data_path(既定 ~/.local/share/weaviate)、binary_path(既定 ~/.cache/weaviate-embedded)です。 ・詳細設定は EmbeddedOptions を使い、additional_env_vars={"ENABLE_MODULES": "..."} のようにモジュールやAPIキーを渡します。設定後 client.connect() で接続します。 ・ログが多い場合は environment_variables={"LOG_LEVEL": "error"} で抑制できます。 ・TypeScriptでは別パッケージ weaviate-ts-embedded をインストールして利用します。 🎯 ユースケース ・CIのユニットテストで、検索ロジックの回帰テストを「インフラ準備ゼロ」で実行する。 ・Jupyterノートブックでのプロトタイピングや実験。 ・ローカルでの単一ユーザー向けの軽量な検証用途。 ⚠️ 注意点 ・実験的ステータスであり、APIやパラメータが変更される可能性があります。 ・単一ノード専用で、クラスタリングや分散デプロイには対応しません。本番用途向けではありません。 ・対応OSはLinuxとmacOSのみです。 ・XDG_DATA_HOME や XDG_CACHE_HOME は他のアプリでも広く使われるため、変更すると他に影響が出る恐れがあります。 #Weaviate# #VectorDatabase#

# Learning Palantir Foundry 🚀 "How many screens do I need to open just to understand one customer?" Object Views answer that pain by bundling everything about a single object into one screen. 📌 Title and Feature URL Title: オブジェクトビュー URL: 📝 Overview Object Views act as the central hub for everything related to a specific object. They consolidate properties, linked objects, metrics and analytics, dashboards, and operational applications into a single unified interface. For example, an Airport object view can integrate flight timelines, delay-handling workflows, and location data in one place. In practice, an Object View becomes the daily "home screen" that frontline users open to start their work. 🔧 How It Works Object Views are highly configurable by builders: - They support multiple formats and sizes, so appearance and interaction patterns can be tailored to the task. - They combine properties (attributes), linked objects, metrics, analytics, and dashboards into one display. - They can be embedded throughout the platform wherever the object appears. - Configuration happens in the Ontology Manager under the "Object views" tab, and version tabs at the top let you switch between format variations. - Selecting "Edit views" opens the configuration editor or the underlying Workshop module. - The system also supports version management, panel variations, commenting, and Marketplace product integration. 🛠 Practical Usage - In Ontology Manager, select the target object type and use the "Object views" tab to preview and configure. - Lay out core information, related objects, operation history, and embedded dashboards so everything the team needs is on one screen. - Beyond viewing, embed action types so users can trigger status changes or assignments directly from the view. - Create multiple formats to show different layouts per role (for example, sales view vs. maintenance view). 🎯 Use Cases - Customer 360: one launchpad combining transaction history, inquiries, related orders, and account owners for sales. - Equipment record: a maintenance home screen with sensor values, service history, related parts, and open tickets. - Case management: a single view of stakeholders, due dates, approval status, and next actions on a case object. ⚠️ Caveats - Views depend on the quality of the underlying ontology modeling (object types and link types); a weak foundation limits view quality. - Overloading a view confuses users, so design role-specific layouts that show only what each role needs. - Editing requires appropriate permissions to the Ontology Manager and the underlying Workshop module. #PalantirFoundry# #DataPlatform#