diff --git a/assets/wechat.jpg b/assets/wechat.jpg index 94893006f..fb83a26b7 100644 Binary files a/assets/wechat.jpg and b/assets/wechat.jpg differ diff --git a/examples/app.py b/examples/app.py deleted file mode 100644 index 07f8a5a51..000000000 --- a/examples/app.py +++ /dev/null @@ -1,74 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding:utf-8 -*- - -import gradio as gr -from langchain.agents import AgentType, initialize_agent, load_tools -from llama_index import ( - Document, - GPTVectorStoreIndex, - LangchainEmbedding, - LLMPredictor, - ServiceContext, -) - -from pilot.model.llm_out.vicuna_llm import VicunaEmbeddingLLM, VicunaRequestLLM - - -def agent_demo(): - llm = VicunaRequestLLM() - - tools = load_tools(["python_repl"], llm=llm) - agent = initialize_agent( - tools, llm, agent=AgentType.CHAT_ZERO_SHOT_REACT_DESCRIPTION, verbose=True - ) - agent.run("Write a SQL script that Query 'select count(1)!'") - - -def knowledged_qa_demo(text_list): - llm_predictor = LLMPredictor(llm=VicunaRequestLLM()) - hfemb = VicunaEmbeddingLLM() - embed_model = LangchainEmbedding(hfemb) - documents = [Document(t) for t in text_list] - - service_context = ServiceContext.from_defaults( - llm_predictor=llm_predictor, embed_model=embed_model - ) - index = GPTVectorStoreIndex.from_documents( - documents, service_context=service_context - ) - return index - - -def get_answer(q): - base_knowledge = """ """ - text_list = [base_knowledge] - index = knowledged_qa_demo(text_list) - response = index.query(q) - return response.response - - -def get_similar(q): - from pilot.vector_store.extract_tovec import knownledge_tovec_st - - docsearch = knownledge_tovec_st("./datasets/plan.md") - docs = docsearch.similarity_search_with_score(q, k=1) - - for doc in docs: - dc, s = doc - print(s) - yield dc.page_content - - -if __name__ == "__main__": - # agent_demo() - - with gr.Blocks() as demo: - gr.Markdown("数据库智能助手") - with gr.Tab("知识问答"): - text_input = gr.TextArea() - text_output = gr.TextArea() - text_button = gr.Button() - - text_button.click(get_similar, inputs=text_input, outputs=text_output) - - demo.queue(concurrency_count=3).launch(server_name="0.0.0.0") diff --git a/examples/embdserver.py b/examples/embdserver.py deleted file mode 100644 index ae0dfcae8..000000000 --- a/examples/embdserver.py +++ /dev/null @@ -1,82 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding:utf-8 -*- - -import json -import os -import sys -from urllib.parse import urljoin - -import gradio as gr -import requests - -ROOT_PATH = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) -sys.path.append(ROOT_PATH) - - -from langchain.prompts import PromptTemplate - -from pilot.configs.config import Config -from pilot.conversation import conv_qa_prompt_template, conv_templates - -llmstream_stream_path = "generate_stream" - -CFG = Config() - - -def generate(query): - template_name = "conv_one_shot" - state = conv_templates[template_name].copy() - - # pt = PromptTemplate( - # template=conv_qa_prompt_template, - # input_variables=["context", "question"] - # ) - - # result = pt.format(context="This page covers how to use the Chroma ecosystem within LangChain. It is broken into two parts: installation and setup, and then references to specific Chroma wrappers.", - # question=query) - - # print(result) - - state.append_message(state.roles[0], query) - state.append_message(state.roles[1], None) - - prompt = state.get_prompt() - params = { - "model": "chatglm-6b", - "prompt": prompt, - "temperature": 1.0, - "max_new_tokens": 1024, - "stop": "###", - } - - response = requests.post( - url=urljoin(CFG.MODEL_SERVER, llmstream_stream_path), data=json.dumps(params) - ) - - skip_echo_len = len(params["prompt"]) + 1 - params["prompt"].count("") * 3 - - for chunk in response.iter_lines(decode_unicode=False, delimiter=b"\0"): - if chunk: - data = json.loads(chunk.decode()) - if data["error_code"] == 0: - if "vicuna" in CFG.LLM_MODEL: - output = data["text"][skip_echo_len:].strip() - else: - output = data["text"].strip() - - state.messages[-1][-1] = output + "▌" - yield (output) - - -if __name__ == "__main__": - print(CFG.LLM_MODEL) - with gr.Blocks() as demo: - gr.Markdown("数据库SQL生成助手") - with gr.Tab("SQL生成"): - text_input = gr.TextArea() - text_output = gr.TextArea() - text_button = gr.Button("提交") - - text_button.click(generate, inputs=text_input, outputs=text_output) - - demo.queue(concurrency_count=3).launch(server_name="0.0.0.0") diff --git a/examples/gpt_index.py b/examples/gpt_index.py deleted file mode 100644 index a4683af1a..000000000 --- a/examples/gpt_index.py +++ /dev/null @@ -1,19 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding: utf-8 -*- - -import logging -import sys - -from llama_index import GPTVectorStoreIndex, SimpleDirectoryReader - -logging.basicConfig(stream=sys.stdout, level=logging.INFO) -logging.getLogger().addHandler(logging.StreamHandler(stream=sys.stdout)) - -# read the document of data dir -documents = SimpleDirectoryReader("data").load_data() -# split the document to chunk, max token size=500, convert chunk to vector - -index = GPTVectorStoreIndex(documents) - -# save index -index.save_to_disk("index.json") diff --git a/examples/gradio_test.py b/examples/gradio_test.py deleted file mode 100644 index 593c6c1f4..000000000 --- a/examples/gradio_test.py +++ /dev/null @@ -1,21 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding:utf-8 -*- - -import gradio as gr - - -def change_tab(): - return gr.Tabs.update(selected=1) - - -with gr.Blocks() as demo: - with gr.Tabs() as tabs: - with gr.TabItem("Train", id=0): - t = gr.Textbox() - with gr.TabItem("Inference", id=1): - i = gr.Image() - - btn = gr.Button() - btn.click(change_tab, None, tabs) - -demo.launch() diff --git a/examples/knowledge_embedding/csv_embedding_test.py b/examples/knowledge_embedding/csv_embedding_test.py deleted file mode 100644 index dcf4873b2..000000000 --- a/examples/knowledge_embedding/csv_embedding_test.py +++ /dev/null @@ -1,18 +0,0 @@ -from pilot.embedding_engine.csv_embedding import CSVEmbedding - -# path = "/Users/chenketing/Downloads/share_ireserve双写数据异常2.xlsx" -path = "xx.csv" -model_name = "your_path/all-MiniLM-L6-v2" -vector_store_path = "your_path/" - - -pdf_embedding = CSVEmbedding( - file_path=path, - model_name=model_name, - vector_store_config={ - "vector_store_name": "url", - "vector_store_path": "vector_store_path", - }, -) -pdf_embedding.source_embedding() -print("success") diff --git a/examples/knowledge_embedding/pdf_embedding_test.py b/examples/knowledge_embedding/pdf_embedding_test.py deleted file mode 100644 index ef0e1d87e..000000000 --- a/examples/knowledge_embedding/pdf_embedding_test.py +++ /dev/null @@ -1,18 +0,0 @@ -from pilot.embedding_engine.pdf_embedding import PDFEmbedding - -path = "xxx.pdf" -path = "your_path/OceanBase-数据库-V4.1.0-应用开发.pdf" -model_name = "your_path/all-MiniLM-L6-v2" -vector_store_path = "your_path/" - - -pdf_embedding = PDFEmbedding( - file_path=path, - model_name=model_name, - vector_store_config={ - "vector_store_name": "ob-pdf", - "vector_store_path": vector_store_path, - }, -) -pdf_embedding.source_embedding() -print("success") diff --git a/examples/knowledge_embedding/url_embedding_test.py b/examples/knowledge_embedding/url_embedding_test.py deleted file mode 100644 index c702fd1f7..000000000 --- a/examples/knowledge_embedding/url_embedding_test.py +++ /dev/null @@ -1,17 +0,0 @@ -from pilot.embedding_engine.url_embedding import URLEmbedding - -path = "https://www.understandingwar.org/backgrounder/russian-offensive-campaign-assessment-february-8-2023" -model_name = "your_path/all-MiniLM-L6-v2" -vector_store_path = "your_path" - - -pdf_embedding = URLEmbedding( - file_path=path, - model_name=model_name, - vector_store_config={ - "vector_store_name": "url", - "vector_store_path": "vector_store_path", - }, -) -pdf_embedding.source_embedding() -print("success") diff --git a/examples/proxy_example.py b/examples/proxy_example.py deleted file mode 100644 index a3d2f3bc4..000000000 --- a/examples/proxy_example.py +++ /dev/null @@ -1,67 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding: utf-8 -*- - -import dashscope -import requests -import hashlib -from http import HTTPStatus -from dashscope import Generation - - -def call_with_messages(): - messages = [ - {"role": "system", "content": "你是生活助手机器人。"}, - {"role": "user", "content": "如何做西红柿鸡蛋？"}, - ] - gen = Generation() - response = gen.call( - Generation.Models.qwen_turbo, - messages=messages, - stream=True, - top_p=0.8, - result_format="message", # set the result to be "message" format. - ) - - for response in response: - # The response status_code is HTTPStatus.OK indicate success, - # otherwise indicate request is failed, you can get error code - # and message from code and message. - if response.status_code == HTTPStatus.OK: - print(response.output) # The output text - print(response.usage) # The usage information - else: - print(response.code) # The error code. - print(response.message) # The error message. - - -def build_access_token(api_key: str, secret_key: str) -> str: - """ - Generate Access token according AK, SK - """ - - url = "https://aip.baidubce.com/oauth/2.0/token" - params = { - "grant_type": "client_credentials", - "client_id": api_key, - "client_secret": secret_key, - } - - res = requests.get(url=url, params=params) - - if res.status_code == 200: - return res.json().get("access_token") - - -def _calculate_md5(text: str) -> str: - md5 = hashlib.md5() - md5.update(text.encode("utf-8")) - encrypted = md5.hexdigest() - return encrypted - - -def baichuan_call(): - url = "https://api.baichuan-ai.com/v1/stream/chat" - - -if __name__ == "__main__": - call_with_messages() diff --git a/examples/t5_example.py b/examples/t5_example.py deleted file mode 100644 index b49e79d4e..000000000 --- a/examples/t5_example.py +++ /dev/null @@ -1,257 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding: utf-8 -*- - -import torch -from langchain.embeddings.huggingface import HuggingFaceEmbeddings -from langchain.llms.base import LLM -from llama_index import ( - GPTListIndex, - GPTVectorStoreIndex, - LangchainEmbedding, - LLMPredictor, - PromptHelper, - SimpleDirectoryReader, -) -from transformers import pipeline - - -class FlanLLM(LLM): - model_name = "google/flan-t5-large" - pipeline = pipeline( - "text2text-generation", - model=model_name, - device=0, - model_kwargs={"torch_dtype": torch.bfloat16}, - ) - - def _call(self, prompt, stop=None): - return self.pipeline(prompt, max_length=9999)[0]["generated_text"] - - def _identifying_params(self): - return {"name_of_model": self.model_name} - - def _llm_type(self): - return "custome" - - -llm_predictor = LLMPredictor(llm=FlanLLM()) -hfemb = HuggingFaceEmbeddings() -embed_model = LangchainEmbedding(hfemb) - -text1 = """ - 执行计划是对一条 SQL 查询语句在数据库中执行过程的描述。用户可以通过 EXPLAIN 命令查看优化器针对指定 SQL 生成的逻辑执行计划。 - -如果要分析某条 SQL 的性能问题，通常需要先查看 SQL 的执行计划，排查每一步 SQL 执行是否存在问题。所以读懂执行计划是 SQL 优化的先决条件，而了解执行计划的算子是理解 EXPLAIN 命令的关键。 - -OceanBase 数据库的执行计划命令有三种模式：EXPLAIN BASIC、EXPLAIN 和 EXPLAIN EXTENDED。这三种模式对执行计划展现不同粒度的细节信息: - -EXPLAIN BASIC 命令用于最基本的计划展示。 - -EXPLAIN EXTENDED 命令用于最详细的计划展示（通常在排查问题时使用这种展示模式）。 - -EXPLAIN 命令所展示的信息可以帮助普通用户了解整个计划的执行方式。 - -EXPLAIN 命令格式如下： -EXPLAIN [BASIC | EXTENDED | PARTITIONS | FORMAT = format_name] [PRETTY | PRETTY_COLOR] explainable_stmt -format_name: - { TRADITIONAL | JSON } -explainable_stmt: - { SELECT statement - | DELETE statement - | INSERT statement - | REPLACE statement - | UPDATE statement } - - -EXPLAIN 命令适用于 SELECT、DELETE、INSERT、REPLACE 和 UPDATE 语句，显示优化器所提供的有关语句执行计划的信息，包括如何处理该语句，如何联接表以及以何种顺序联接表等信息。 - -一般来说，可以使用 EXPLAIN EXTENDED 命令，将表扫描的范围段展示出来。使用 EXPLAIN OUTLINE 命令可以显示 Outline 信息。 - -FORMAT 选项可用于选择输出格式。TRADITIONAL 表示以表格格式显示输出，这也是默认设置。JSON 表示以 JSON 格式显示信息。 - -使用 EXPLAIN PARTITITIONS 也可用于检查涉及分区表的查询。如果检查针对非分区表的查询，则不会产生错误，但 PARTIONS 列的值始终为 NULL。 - -对于复杂的执行计划，可以使用 PRETTY 或者 PRETTY_COLOR 选项将计划树中的父节点和子节点使用树线或彩色树线连接起来，使得执行计划展示更方便阅读。示例如下： -obclient> CREATE TABLE p1table(c1 INT ,c2 INT) PARTITION BY HASH(c1) PARTITIONS 2; -Query OK, 0 rows affected - -obclient> CREATE TABLE p2table(c1 INT ,c2 INT) PARTITION BY HASH(c1) PARTITIONS 4; -Query OK, 0 rows affected - -obclient> EXPLAIN EXTENDED PRETTY_COLOR SELECT * FROM p1table p1 JOIN p2table p2 ON p1.c1=p2.c2\G -*************************** 1. row *************************** -Query Plan: ========================================================== -|ID|OPERATOR |NAME |EST. ROWS|COST| ----------------------------------------------------------- -|0 |PX COORDINATOR | |1 |278 | -|1 | EXCHANGE OUT DISTR |:EX10001|1 |277 | -|2 | HASH JOIN | |1 |276 | -|3 | ├PX PARTITION ITERATOR | |1 |92 | -|4 | │ TABLE SCAN |P1 |1 |92 | -|5 | └EXCHANGE IN DISTR | |1 |184 | -|6 | EXCHANGE OUT DISTR (PKEY)|:EX10000|1 |184 | -|7 | PX PARTITION ITERATOR | |1 |183 | -|8 | TABLE SCAN |P2 |1 |183 | -========================================================== - -Outputs & filters: -------------------------------------- - 0 - output([INTERNAL_FUNCTION(P1.C1, P1.C2, P2.C1, P2.C2)]), filter(nil) - 1 - output([INTERNAL_FUNCTION(P1.C1, P1.C2, P2.C1, P2.C2)]), filter(nil), dop=1 - 2 - output([P1.C1], [P2.C2], [P1.C2], [P2.C1]), filter(nil), - equal_conds([P1.C1 = P2.C2]), other_conds(nil) - 3 - output([P1.C1], [P1.C2]), filter(nil) - 4 - output([P1.C1], [P1.C2]), filter(nil), - access([P1.C1], [P1.C2]), partitions(p[0-1]) - 5 - output([P2.C2], [P2.C1]), filter(nil) - 6 - (#keys=1, [P2.C2]), output([P2.C2], [P2.C1]), filter(nil), dop=1 - 7 - output([P2.C1], [P2.C2]), filter(nil) - 8 - output([P2.C1], [P2.C2]), filter(nil), - access([P2.C1], [P2.C2]), partitions(p[0-3]) - -1 row in set - - - - -## 执行计划形状与算子信息 - -在数据库系统中，执行计划在内部通常是以树的形式来表示的，但是不同的数据库会选择不同的方式展示给用户。 - -如下示例分别为 PostgreSQL 数据库、Oracle 数据库和 OceanBase 数据库对于 TPCDS Q3 的计划展示。 - -```sql -obclient> SELECT /*TPC-DS Q3*/ * - FROM (SELECT dt.d_year, - item.i_brand_id brand_id, - item.i_brand brand, - Sum(ss_net_profit) sum_agg - FROM date_dim dt, - store_sales, - item - WHERE dt.d_date_sk = store_sales.ss_sold_date_sk - AND store_sales.ss_item_sk = item.i_item_sk - AND item.i_manufact_id = 914 - AND dt.d_moy = 11 - GROUP BY dt.d_year, - item.i_brand, - item.i_brand_id - ORDER BY dt.d_year, - sum_agg DESC, - brand_id) - WHERE ROWNUM <= 100; - -PostgreSQL 数据库执行计划展示如下： -Limit (cost=13986.86..13987.20 rows=27 width=91) - Sort (cost=13986.86..13986.93 rows=27 width=65) - Sort Key: dt.d_year, (sum(store_sales.ss_net_profit)), item.i_brand_id - HashAggregate (cost=13985.95..13986.22 rows=27 width=65) - Merge Join (cost=13884.21..13983.91 rows=204 width=65) - Merge Cond: (dt.d_date_sk = store_sales.ss_sold_date_sk) - Index Scan using date_dim_pkey on date_dim dt (cost=0.00..3494.62 rows=6080 width=8) - Filter: (d_moy = 11) - Sort (cost=12170.87..12177.27 rows=2560 width=65) - Sort Key: store_sales.ss_sold_date_sk - Nested Loop (cost=6.02..12025.94 rows=2560 width=65) - Seq Scan on item (cost=0.00..1455.00 rows=16 width=59) - Filter: (i_manufact_id = 914) - Bitmap Heap Scan on store_sales (cost=6.02..658.94 rows=174 width=14) - Recheck Cond: (ss_item_sk = item.i_item_sk) - Bitmap Index Scan on store_sales_pkey (cost=0.00..5.97 rows=174 width=0) - Index Cond: (ss_item_sk = item.i_item_sk) - - - -Oracle 数据库执行计划展示如下： -Plan hash value: 2331821367 --------------------------------------------------------------------------------------------------- -| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------- -| 0 | SELECT STATEMENT | | 100 | 9100 | 3688 (1)| 00:00:01 | -|* 1 | COUNT STOPKEY | | | | | | -| 2 | VIEW | | 2736 | 243K| 3688 (1)| 00:00:01 | -|* 3 | SORT ORDER BY STOPKEY | | 2736 | 256K| 3688 (1)| 00:00:01 | -| 4 | HASH GROUP BY | | 2736 | 256K| 3688 (1)| 00:00:01 | -|* 5 | HASH JOIN | | 2736 | 256K| 3686 (1)| 00:00:01 | -|* 6 | TABLE ACCESS FULL | DATE_DIM | 6087 | 79131 | 376 (1)| 00:00:01 | -| 7 | NESTED LOOPS | | 2865 | 232K| 3310 (1)| 00:00:01 | -| 8 | NESTED LOOPS | | 2865 | 232K| 3310 (1)| 00:00:01 | -|* 9 | TABLE ACCESS FULL | ITEM | 18 | 1188 | 375 (0)| 00:00:01 | -|* 10 | INDEX RANGE SCAN | SYS_C0010069 | 159 | | 2 (0)| 00:00:01 | -| 11 | TABLE ACCESS BY INDEX ROWID| STORE_SALES | 159 | 2703 | 163 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------- - -OceanBase 数据库执行计划展示如下： -|ID|OPERATOR |NAME |EST. ROWS|COST | -------------------------------------------------------- -|0 |LIMIT | |100 |81141| -|1 | TOP-N SORT | |100 |81127| -|2 | HASH GROUP BY | |2924 |68551| -|3 | HASH JOIN | |2924 |65004| -|4 | SUBPLAN SCAN |VIEW1 |2953 |19070| -|5 | HASH GROUP BY | |2953 |18662| -|6 | NESTED-LOOP JOIN| |2953 |15080| -|7 | TABLE SCAN |ITEM |19 |11841| -|8 | TABLE SCAN |STORE_SALES|161 |73 | -|9 | TABLE SCAN |DT |6088 |29401| -======================================================= - -由示例可见，OceanBase 数据库的计划展示与 Oracle 数据库类似。 - -OceanBase 数据库执行计划中的各列的含义如下： -列名 含义 -ID 执行树按照前序遍历的方式得到的编号（从 0 开始）。 -OPERATOR 操作算子的名称。 -NAME 对应表操作的表名（索引名）。 -EST. ROWS 估算该操作算子的输出行数。 -COST 该操作算子的执行代价（微秒）。 - - -OceanBase 数据库 EXPLAIN 命令输出的第一部分是执行计划的树形结构展示。其中每一个操作在树中的层次通过其在 operator 中的缩进予以展示，层次最深的优先执行，层次相同的以特定算子的执行顺序为标准来执行。 - -问题: update a not exists (b…) -我一开始以为 B是驱动表，B的数据挺多的 后来看到NLAJ，是说左边的表关联右边的表 -所以这个的驱动表是不是实际是A，用A的匹配B的，这个理解有问题吗 - -回答: 没错 A 驱动 B的 - -问题: 光知道最下最右的是驱动表了 所以一开始搞得有点懵 :sweat_smile: - -回答: nlj应该原理应该都是左表(驱动表)的记录探测右表(被驱动表)， 选哪张成为左表或右表就基于一些其他考量了，比如数据量， 而anti join/semi join只是对 not exist/exist的一种优化，相关的原理和资料网上可以查阅一下 - -问题: 也就是nlj 就是按照之前理解的谁先执行 谁就是驱动表 也就是执行计划中的最右的表 -而anti join/semi join，谁在not exist左面，谁就是驱动表。这么理解对吧 - -回答: nlj也是左表的表是驱动表，这个要了解下计划执行方面的基本原理，取左表的一行数据，再遍历右表，一旦满足连接条件，就可以返回数据 -anti/semi只是因为not exists/exist的语义只是返回左表数据，改成anti join是一种计划优化，连接的方式比子查询更优 -""" - -from llama_index import Document - -text_list = [text1] -documents = [Document(t) for t in text_list] - -num_output = 250 -max_input_size = 512 - -max_chunk_overlap = 20 -prompt_helper = PromptHelper(max_input_size, num_output, max_chunk_overlap) - -index = GPTListIndex( - documents, - embed_model=embed_model, - llm_predictor=llm_predictor, - prompt_helper=prompt_helper, -) -index.save_to_disk("index.json") - - -if __name__ == "__main__": - import logging - - logging.getLogger().setLevel(logging.CRITICAL) - for d in documents: - print(d) - - response = index.query("数据库的执行计划命令有多少?") - print(response) diff --git a/pilot/datasets/mysql/url.md b/pilot/datasets/mysql/url.md deleted file mode 100644 index 20592cb72..000000000 --- a/pilot/datasets/mysql/url.md +++ /dev/null @@ -1 +0,0 @@ -LlamaIndex是一个数据框架，旨在帮助您构建LLM应用程序。它包括一个向量存储索引和一个简单的目录阅读器，可以帮助您处理和操作数据。此外，LlamaIndex还提供了一个GPT Index，可以用于数据增强和生成更好的LM模型。 \ No newline at end of file diff --git a/pilot/datasets/oceanbase/OceanBase_Introduction.md b/pilot/datasets/oceanbase/OceanBase_Introduction.md deleted file mode 100644 index 2cb6e9538..000000000 --- a/pilot/datasets/oceanbase/OceanBase_Introduction.md +++ /dev/null @@ -1,206 +0,0 @@ -OceanBase 数据库（OceanBase Database）是一款完全自研的企业级原生分布式数据库，在普通硬件上实现金融级高可用，首创“三地五中心”城市级故障自动无损容灾新标准，刷新 TPC-C 标准测试，单集群规模超过 1500 节点，具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性。 - -核心特性 -高可用 -独创 “三地五中心” 容灾架构方案，建立金融行业无损容灾新标准。支持同城/异地容灾，可实现多地多活，满足金融行业 6 级容灾标准（RPO=0，RTO< 8s），数据零丢失。 -高兼容 -高度兼容 Oracle 和 MySQL，覆盖绝大多数常见功能，支持过程语言、触发器等高级特性，提供自动迁移工具，支持迁移评估和反向同步以保障数据迁移安全，可支撑金融、政府、运营商等关键行业核心场景替代。 -水平扩展 -实现透明水平扩展，支持业务快速的扩容缩容，同时通过准内存处理架构实现高性能。支持集群节点超过数千个，单集群最大数据量超过 3PB，最大单表行数达万亿级。 -低成本 -基于 LSM-Tree 的高压缩引擎，存储成本降低 70% - 90%；原生支持多租户架构，同集群可为多个独立业务提供服务，租户间数据隔离，降低部署和运维成本。 -实时 HTAP -基于“同一份数据，同一个引擎”，同时支持在线实时交易及实时分析两种场景，“一份数据”的多个副本可以存储成多种形态，用于不同工作负载，从根本上保持数据一致性。 -安全可靠 -12 年完全自主研发，代码级可控，自研单机分布式一体化架构，大规模金融核心场景 9 年可靠性验证；完备的角色权限管理体系，数据存储和通信全链路透明加密，支持国密算法，通过等保三级专项合规检测。 -深入了解 OceanBase 数据库 -您可以通过以下内容更深入地了解 OceanBase 数据库： - -OceanBase 使用通用服务器硬件，依赖本地存储，分布式部署使用的多个服务器也是对等的，没有特殊的硬件要求。OceanBase 的分布式数据库处理采用 Shared Nothing 架构，数据库内的 SQL 执行引擎具有分布式执行能力。 - -OceanBase 在服务器上会运行叫做 observer 的单进程程序作为数据库的运行实例，使用本地的文件存储数据和事务 Redo 日志。 - -OceanBase 集群部署需要配置可用区（Zone），由若干个服务器组成。可用区是一个逻辑概念，表示集群内具有相似硬件可用性的一组节点，它在不同的部署模式下代表不同的含义。例如，当整个集群部署在同一个数据中心（IDC）内的时候，一个可用区的节点可以属于同一个机架，同一个交换机等。当集群分布在多个数据中心的时候，每个可用区可以对应于一个数据中心。 - -用户存储的数据在分布式集群内部可以存储多个副本，用于故障容灾，也可以用于分散读取压力。在一个可用区内部数据只有一个副本，不同的可用区可以存储同一个数据的多个副本，副本之间由共识协议保证数据的一致性。 - -OceanBase 内置多租户特性，每个租户对于使用者是一个独立的数据库，一个租户能够在租户级别设置租户的分布式部署方式。租户之间 CPU、内存和 IO 都是隔离的。 - -OceanBase的数据库实例内部由不同的组件相互协作，这些组件从底层向上由存储层、复制层、均衡层、事务层、SQL 层、接入层组成。 - -存储层 -存储层以一张表或者一个分区为粒度提供数据存储与访问，每个分区对应一个用于存储数据的Tablet（分片），用户定义的非分区表也会对应一个 Tablet。 - -Tablet 的内部是分层存储的结构，总共有 4 层。DML 操作插入、更新、删除等首先写入 MemTable，等到 MemTable 达到一定大小时转储到磁盘成为 L0 SSTable。L0 SSTable 个数达到阈值后会将多个 L0 SSTable 合并成一个 L1 SSTable。在每天配置的业务低峰期，系统会将所有的 MemTable、L0 SSTable 和 L1 SSTable 合并成一个 Major SSTable。 - -每个 SSTable 内部是以 2MB 定长宏块为基本单位，每个宏块内部由多个不定长微块组成。 - -Major SSTable 的微块会在合并过程中用编码方式进行格式转换，微块内的数据会按照列维度分别进行列内的编码，编码规则包括字典/游程/常量/差值等，每一列压缩结束后，还会进一步对多列进行列间等值/子串等规则编码。编码能对数据大幅压缩，同时提炼的列内特征信息还能进一步加速后续的查询速度。 - -在编码压缩之后，还可以根据用户指定的通用压缩算法进行无损压缩，进一步提升数据压缩率。 - -复制层 -复制层使用日志流（LS、Log Stream）在多副本之间同步状态。每个 Tablet 都会对应一个确定的日志流，DML 操作写入 Tablet 的数据所产生的 Redo 日志会持久化在日志流中。日志流的多个副本会分布在不同的可用区中，多个副本之间维持了共识算法，选择其中一个副本作为主副本，其他的副本皆为从副本。Tablet 的 DML 和强一致性查询只在其对应的日志流的主副本上进行。 - -通常情况下，每个租户在每台机器上只会有一个日志流的主副本，可能存在多个其他日志流的从副本。租户的总日志流个数取决于 Primary Zone 和 Locality 的配置。 - -日志流使用自研的 Paxos 协议将 Redo 日志在本服务器持久化，同时通过网络发送给日志流的从副本，从副本在完成各自持久化后应答主副本，主副本在确认有多数派副本都持久化成功后确认对应的 Redo 日志持久化成功。从副本利用 Redo 日志的内容实时回放，保证自己的状态与主副本一致。 - -日志流的主副本在被选举成为主后会获得租约（Lease），正常工作的主副本在租约有效期内会不停的通过选举协议延长租约期。主副本只会在租约有效时执行主的工作，租约机制保证了数据库异常处理的能力。 - -复制层能够自动应对服务器故障，保障数据库服务的持续可用。如果出现少于半数的从副本所在服务器出现问题，因为还有多于半数的副本正常工作，数据库的服务不受影响。如果主副本所在服务器出现问题，其租约会得不到延续，待其租约失效后，其他从副本会通过选举协议选举出新的主副本并授予新的租约，之后即可恢复数据库的服务。 - -均衡层 -新建表和新增分区时，系统会按照均衡原则选择合适的日志流创建 Tablet。当租户的属性发生变更，新增了机器资源，或者经过长时间使用后，Tablet 在各台机器上不再均衡时，均衡层通过日志流的分裂和合并操作，并在这个过程中配合日志流副本的移动，让数据和服务在多个服务器之间再次均衡。 - -当租户有扩容操作，获得更多服务器资源时，均衡层会将租户内已有的日志流进行分裂，并选择合适数量的 Tablet 一同分裂到新的日志流中，再将新日志流迁移到新增的服务器上，以充分利用扩容后的资源。当租户有缩容操作时，均衡层会把需要缩减的服务器上的日志流迁移到其他服务器上，并和其他服务器上已有的日志流进行合并，以缩减机器的资源占用。 - -当数据库长期使用后，随着持续创建删除表格，并且写入更多的数据，即使没有服务器资源数量变化，原本均衡的情况可能被破坏。最常见的情况是，当用户删除了一批表格后，删除的表格可能原本聚集在某一些机器上，删除后这些机器上的 Tablet 数量就变少了，应该把其他机器的 Tablet 均衡一些到这些少的机器上。均衡层会定期生成均衡计划，将 Tablet 多的服务器上日志流分裂出临时日志流并携带需要移动的 Tablet，临时日志流迁移到目的服务器后再和目的服务器上的日志流进行合并，以达成均衡的效果。 - -事务层 -事务层保证了单个日志流和多个日志流DML操作提交的原子性，也保证了并发事务之间的多版本隔离能力。 - -原子性 -一个日志流上事务的修改，即使涉及多个 Tablet，通过日志流的 write-ahead log 可以保证事务提交的原子性。事务的修改涉及多个日志流时，每个日志流会产生并持久化各自的write-ahead log，事务层通过优化的两阶段提交协议来保证提交的原子性。 - -事务层会选择一个事务修改的一个日志流产生协调者状态机，协调者会与事务修改的所有日志流通信，判断 write-ahead log 是否持久化，当所有日志流都完成持久化后，事务进入提交状态，协调者会再驱动所有日志流写下这个事务的 Commit 日志，表示事务最终的提交状态。当从副本回放或者数据库重启时，已经完成提交的事务都会通过 Commit 日志确定各自日志流事务的状态。 - -宕机重启场景下，宕机前还未完成的事务，会出现写完 write-ahead log 但是还没有Commit 日志的情况，每个日志流的 write-ahead log 都会包含事务的所有日志流列表，通过此信息可以重新确定哪个日志流是协调者并恢复协调者的状态，再次推进两阶段状态机，直到事务最终的 Commit 或 Abort 状态。 - -隔离性 -GTS 服务是一个租户内产生连续增长的时间戳的服务，其通过多副本保证可用性，底层机制与上面复制层所描述的日志流副本同步机制是一样的。 - -每个事务在提交时会从 GTS 获取一个时间戳作为事务的提交版本号并持久化在日志流的write-ahead log 中，事务内所有修改的数据都以此提交版本号标记。 - -每个语句开始时（对于 Read Committed 隔离级别）或者每个事务开始时（对于Repeatable Read 和 Serializable 隔离级别）会从 GTS 获取一个时间戳作为语句或事务的读取版本号。在读取数据时，会跳过事务版本号比读取版本号大的数据，通过这种方式为读取操作提供了统一的全局数据快照。 - -SQL 层 -SQL 层将用户的 SQL 请求转化成对一个或多个 Tablet 的数据访问。 - -SQL 层组件 -SQL 层处理一个请求的执行流程是：Parser、Resolver、Transformer、Optimizer、Code Generator、Executor。 - -Parser 负责词法/语法解析，Parser 会将用户的 SQL 分成一个个的 "Token"，并根据预先设定好的语法规则解析整个请求，转换成语法树（Syntax Tree）。 - -Resolver 负责语义解析，将根据数据库元信息将 SQL 请求中的 Token 翻译成对应的对象（例如库、表、列、索引等），生成的数据结构叫做 Statement Tree。 - -Transformer 负责逻辑改写，根据内部的规则或代价模型，将 SQL 改写为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化。Transformer 的工作方式是在原Statement Tree 上做等价变换，变换的结果仍然是一棵 Statement Tree。 - -Optimizer（优化器）为 SQL 请求生成最佳的执行计划，需要综合考虑 SQL 请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、联接顺序选择、联接算法选择、分布式计划生成等问题，最终生成执行计划。 - -Code Generator（代码生成器）将执行计划转换为可执行的代码，但是不做任何优化选择。 - -Executor（执行器）启动 SQL 的执行过程。 - -在标准的 SQL 流程之外，SQL 层还有 Plan Cache 能力，将历史的执行计划缓存在内存中，后续的执行可以反复执行这个计划，避免了重复查询优化的过程。配合 Fast-parser 模块，仅使用词法分析对文本串直接参数化，获取参数化后的文本及常量参数，让 SQL 直接命中 Plan Cache，加速频繁执行的 SQL。 - -多种计划 -SQL 层的执行计划分为本地、远程和分布式三种。本地执行计划只访问本服务器的数据。远程执行计划只访问非本地的一台服务器的数据。分布式计划会访问超过一台服务器的数据，执行计划会分成多个子计划在多个服务器上执行。 - -SQL 层并行化执行能力可以将执行计划分解成多个部分，由多个执行线程执行，通过一定的调度的方式，实现执行计划的并行处理。并行化执行可以充分发挥服务器 CPU 和 IO 处理能力，缩短单个查询的响应时间。并行查询技术可以用于分布式执行计划，也可以用于本地执行计划。 - -接入层 -obproxy 是 OceanBase 数据库的接入层，负责将用户的请求转发到合适的 OceanBase 实例上进行处理。 - -obproxy 是独立的进程实例，独立于 OceanBase 的数据库实例部署。obproxy 监听网络端口，兼容 MySQL 网络协议，支持使用 MySQL 驱动的应用直接连接 OceanBase。 - -obproxy 能够自动发现 OceanBase 集群的数据分布信息，对于代理的每一条 SQL 语句，会尽可能识别出语句将访问的数据，并将语句直接转发到数据所在服务器的 OceanBase 实例。 - -obproxy 有两种部署方式，一种是部署在每一个需要访问数据库的应用服务器上，另一种是部署在与 OceanBase 相同的机器上。第一种部署方式下，应用程序直接连接部署在同一台服务器上的 obproxy，所有的请求会由 obproxy 发送到合适的 OceanBase 服务器。第二种部署方式下，需要使用网络负载均衡服务将多个 obproxy 聚合成同一个对应用提供服务的入口地址。 - -OceanBase 数据库采用 Shared-Nothing 架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎、事务引擎，运行在普通 PC 服务器组成的集群之上，具备高可扩展性、高可用性、高性能、低成本、与主流数据库高兼容等核心特性。 - -OceanBase 数据库的一个集群由若干个节点组成。这些节点分属于若干个可用区（Zone），每个节点属于一个可用区。可用区是一个逻辑概念，表示集群内具有相似硬件可用性的一组节点，它在不同的部署模式下代表不同的含义。例如，当整个集群部署在同一个数据中心（IDC）内的时候，一个可用区的节点可以属于同一个机架，同一个交换机等。当集群分布在多个数据中心的时候，每个可用区可以对应于一个数据中心。每个可用区具有 IDC 和地域（Region）两个属性，描述该可用区所在的 IDC 及 IDC 所属的地域。一般地，地域指 IDC 所在的城市。可用区的 IDC 和 Region 属性需要反映部署时候的实际情况，以便集群内的自动容灾处理和优化策略能更好地工作。根据业务对数据库系统不同的高可用性需求，OceanBase 集群提供了多种部署模式，参见 高可用架构概述。 - -在 OceanBase 数据库中，一个表的数据可以按照某种划分规则水平拆分为多个分片，每个分片叫做一个表分区，简称分区（Partition）。某行数据属于且只属于一个分区。分区的规则由用户在建表的时候指定，包括hash、range、list等类型的分区，还支持二级分区。例如，交易库中的订单表，可以先按照用户 ID 划分为若干一级分区，再按照月份把每个一级分区划分为若干二级分区。对于二级分区表，第二级的每个子分区是一个物理分区，而第一级分区只是逻辑概念。一个表的若干个分区可以分布在一个可用区内的多个节点上。每个物理分区有一个用于存储数据的存储层对象，叫做 Tablet ，用于存储有序的数据记录。 - -当用户对 Tablet 中记录进行修改的时候，为了保证数据持久化，需要记录重做日志（REDO）到 Tablet 对应的日志流（Log Stream）里。每个日志流服务了其所在节点上的多个 Tablet。为了能够保护数据，并在节点发生故障的时候不中断服务，每个日志流及其所属的 Tablet 有多个副本。一般来说，多个副本分散在多个不同的可用区里。多个副本中有且只有一个副本接受修改操作，叫做主副本（Leader），其他副本叫做从副本（Follower）。主从副本之间通过基于 Multi-Paxos 的分布式共识协议实现了副本之间数据的一致性。当主副本所在节点发生故障的时候，一个从副本会被选举为新的主副本并继续提供服务。 - -在集群的每个节点上会运行一个叫做 observer 的服务进程，它内部包含多个操作系统线程。节点的功能都是对等的。每个服务负责自己所在节点上分区数据的存取，也负责路由到本机的 SQL 语句的解析和执行。这些服务进程之间通过 TCP/IP 协议进行通信。同时，每个服务会监听来自外部应用的连接请求，建立连接和数据库会话，并提供数据库服务。关于 observer 服务进程的更多信息，参见 线程简介。 - -为了简化大规模部署多个业务数据库的管理并降低资源成本，OceanBase 数据库提供了独特的多租户特性。在一个 OceanBase 集群内，可以创建很多个互相之间隔离的数据库"实例"，叫做一个租户。从应用程序的视角来看，每个租户是一个独立的数据库。不仅如此，每个租户可以选择 MySQL 或 Oracle 兼容模式。应用连接到 MySQL 租户后，可以在租户下创建用户、database，与一个独立的 MySQL 库的使用体验是一样的。同样的，应用连接到 Oracle 租户后，可以在租户下创建 schema、管理角色等，与一个独立的 Oracle 库的使用体验是一样的。一个新的集群初始化之后，就会存在一个特殊的名为 sys 的租户，叫做系统租户。系统租户中保存了集群的元数据，是一个 MySQL 兼容模式的租户。 - -为了隔离租户的资源，每个 observer 进程内可以有多个属于不同租户的虚拟容器，叫做资源单元（UNIT）。每个租户在多个节点上的资源单元组成一个资源池。资源单元包括 CPU 和内存资源。 - -为了使 OceanBase 数据库对应用程序屏蔽内部分区和副本分布等细节，使应用访问分布式数据库像访问单机数据库一样简单，我们提供了 obproxy 代理服务。应用程序并不会直接与 OBServer 建立连接，而是连接obproxy，然后由 obproxy 转发 SQL 请求到合适的 OBServer 节点。obproxy 是无状态的服务，多个 obproxy 节点通过网络负载均衡（SLB）对应用提供统一的网络地址。 - - -OceanBase 数据库是随着阿里巴巴电商业务的发展孕育而生，随着蚂蚁集团移动支付业务的发展而壮大，经过十多年各类业务的使用和打磨才终于破茧成蝶，推向了外部市场。本章节简述 OceanBase 数据库发展过程中一些里程碑意义的事件。 - -诞生 - -2010 年，OceanBase 创始人阳振坤博士带领初创团队启动了 OceanBase 项目。第一个应用是淘宝的收藏夹业务。如今收藏夹依然是 OceanBase 的客户。收藏夹单表数据量非常大，OceanBase 用独创的方法解决了其高并发的大表连接小表的需求。 - -关系数据库 - -早期的版本中，应用通过定制的 API 库访问 OceanBase 数据库。2012 年，OceanBase 数据库发布了支持 SQL 的版本，初步成为一个功能完整的通用关系数据库。 - -初试金融业务 - -OceanBase 进入支付宝（后来的蚂蚁集团），开始应用于金融级的业务场景。2014 年"双 11"大促活动，OceanBase 开始承担交易库部分流量。此后，新成立的网商银行把所有核心交易库都运行在 OceanBase 数据库上。 - -金融级核心库 - -2016 年，OceanBase 数据库发布了架构重新设计后的 1.0 版本，支持了分布式事务，提升了高并发写业务中的扩展，同时实现了多租户架构，这个整体架构延续至今。同时，到 2016 年"双 11"时，支付宝全部核心库的业务流量 100% 运行在 OceanBase 数据库上，包括交易、支付、会员和最重要的账务库。 - -走向外部市场 - -2017 年，OceanBase 数据库开始试点外部业务，成功应用于南京银行。 - -商业化加速 - -2018 年，OceanBase 数据库发布 2.0 版本，开始支持 Oracle 兼容模式。这一特性降低应用改造适配成本，在外部客户中快速推广开来。 - -勇攀高峰 - -2019 年，OceanBase 数据库 V2.2 版本参加代表 OLTP 数据库最权威的 TPC-C 评测，以 6000 万 tpmC 的成绩登顶世界第一。随后，在 2020 年，又以 7 亿 tpmC 刷新纪录，截止目前依然稳居第一。这充分证明了 OceanBase 数据库优秀的扩展性和稳定性。OceanBase 数据库是第一个也是截止目前唯一一个上榜 TPC-C 的中国数据库产品。 - -HTAP 混合负载 - -2021 年，OceanBase 数据库 V3.0 基于全新的向量化执行引擎，在 TPC-H 30000GB 的评测中以 1526 万 QphH 的成绩刷新了评测榜单。这标志着 OceanBase 数据库一套引擎处理 AP 和 TP 混合负载的能力取得了基础性的突破。 - -开源开放 - -2021 年六一儿童节，OceanBase 数据库宣布全面开源，开放合作，共建生态。 - -OceanBase 数据库采用了单集群多租户设计，天然支持云数据库架构，支持公有云、私有云、混合云等多种部署形式。 - -架构 - -OceanBase 数据库通过租户实现资源隔离，让每个数据库服务的实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性，配合 OceanBase 数据库强大的可扩展性，能够提供安全、灵活的 DBaaS 服务。 - -租户是一个逻辑概念。在 OceanBase 数据库中，租户是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于云数据库的运维有着重要的影响。租户在一定程度上相当于传统数据库的"实例"概念。租户之间是完全隔离的。在数据安全方面，OceanBase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险。在资源使用方面，OceanBase 数据库表现为租户"独占"其资源配额。总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器。 - -OceanBase 数据库在一个系统中可同时支持 MySQL 模式和 Oracle 模式两种模式的租户。用户在创建租户时，可选择创建 MySQL 兼容模式的租户或 Oracle 兼容模式的租户，租户的兼容模式一经确定就无法更改，所有数据类型、SQL 功能、视图等相应地与 MySQL 数据库或 Oracle 数据库保持一致。 - - -MySQL 模式 -MySQL 模式是为降低 MySQL 数据库迁移至 OceanBase 数据库所引发的业务系统改造成本，同时使业务数据库设计人员、开发人员、数据库管理员等可复用积累的 MySQL 数据库技术知识经验，并能快速上手 OceanBase 数据库而支持的一种租户类型功能。OceanBase 数据库的 MySQL 模式兼容 MySQL 5.7 的绝大部分功能和语法，兼容 MySQL 5.7 版本的全量以及 8.0 版本的部分 JSON 函数，基于 MySQL 的应用能够平滑迁移。 - -Oracle 模式 -OceanBase 数据库从 V2.x.x 版本开始支持 Oracle 兼容模式。Oracle 模式是为降低 Oracle 数据库迁移 OceanBase 数据库的业务系统改造成本，同时使业务数据库设计开发人员、数据库管理员等可复用积累的 Oracle 数据库技术知识经验，并能快速上手 OceanBase 数据库而支持的一种租户类型功能。Oracle 模式目前能够支持绝大部分的 Oracle 语法和过程性语言功能，可以做到大部分的 Oracle 业务进行少量修改后的自动迁移。 - -OceanBase 数据库是多租户架构。在 V4.0.0 版本之前，仅支持两种类型的租户：系统租户和用户租户。从 V4.0.0 版本开始，引入了 Meta 租户概念。因此，当前版本对用户可见的租户有三种类型：系统租户、用户租户以及 Meta 租户。 - -系统租户 -系统租户是集群默认创建的租户，与集群的生命周期一致，负责管理集群和所有租户的生命周期。系统租户仅有一个 1 号日志流，仅支持单点写入，不具备扩展能力。 - -系统租户可以创建用户表，所有的用户表和系统表数据均由 1 号日志流服务。系统租户的数据是集群私有的，不支持主备集群物理同步和物理备份恢复。 - -用户租户 -用户租户是由用户创建的租户，对外提供完整的数据库功能，支持 MySQL 和 Oracle 两种兼容模式。用户租户支持服务能力水平扩展到多台机器上，支持动态扩容和缩容，内部会根据用户的配置自动创建和删除日志流。 - -用户租户的数据有更强的数据保护和可用性要求，支持跨集群物理同步和物理备份恢复，典型数据包括：Schema 数据、用户表数据及事务数据等。 -Meta 租户 -Meta 租户是 OceanBase 数据库内部自管理的租户，每创建一个用户租户系统就会自动创建一个对应的 Meta 租户，其生命期与用户租户保持一致。 - -Meta 租户用于存储和管理用户租户的集群私有数据，这部分数据不需要进行跨库物理同步以及物理备份恢复，这些数据包括：配置项、位置信息、副本信息、日志流状态、备份恢复相关信息、合并信息等。 - -租户对比 -从用户角度来看，系统租户、用户租户和 Meta 租户的差异性如下表所示。 -OceanBase 数据库是多租户的数据库系统，一个集群内可包含多个相互独立的租户，每个租户提供独立的数据库服务。在 OceanBase 数据库中，使用资源配置（unit_config）、资源池（Resource Pool）和资源单元（Unit）三个概念，对各租户的可用资源进行管理。 - - -创建租户前，需首先确定租户的资源配置、使用资源范围等。租户创建的通用流程如下： - -资源配置是描述资源池的配置信息，用来描述资源池中每个资源单元可用的 CPU、内存、存储空间和 IOPS 等的规格。修改资源配置可动态调整资源单元的规格。这里需要注意，资源配置指定的是对应资源单元能够提供的服务能力，而不是资源单元的实时负载。 创建资源配置的示例语句如下： \ No newline at end of file diff --git a/pilot/mock_datas/db-gpt-test.db b/pilot/mock_datas/db-gpt-test.db deleted file mode 100644 index 4dd7921b4..000000000 Binary files a/pilot/mock_datas/db-gpt-test.db and /dev/null differ