Category Archives: Database

Database

問個資料庫的問題。現在是否有符合下面這些條件的資料庫:

  • 只要有 (key,value) 即可,不需要到 SQL 那種複雜的架構
  • 可以用多台機器 Cluster,並且有 Replication,不受到單一機器的 Bottleneck
  • 不存在 Single Point of Failure
  • 可線上擴充機器

的 Replication (即 Single Master, Read-only Slave) 最後會卡在 Writing,而且空間的消耗讓人不是很滿意。 的架構仍然有 Single Point of Failure (我想他們應該是用 Layer 4 Switch 或是其他配合硬體的方式解決),所以我想問的是,有沒有數學方法就可以滿足上面要求的資料庫?

Update:我希望每個 node 都是 1TB,初期大約三十台到六十台機器,以後可以擴充到上千台,每個 key 都會有四份資料放在 DB 裡面。

INSERT ... ON DUPLICATE KEY UPDATE

把放很久的文章整理出來。

這裡看到 4.1 之後的版本可以有 INSERT ... ON DUPLICATE KEY UPDATE 這種用法:MySQL Counters。引用的原文在 INSERT ON DUPLICATE KEY UPDATE and summary counters. 這篇。

如果你對於 race condition 有瞭解,你可以在文章裡看到這種用法將本來要自己做的檢查交給 處理:

INSERT INTO ipstat VALUES(inet_aton('192.168.0.1'), 1, now()) ON duplicate KEY UPDATE hits = hits + 1;

這個功能在 4.1 以及之後的版本有提供。

Lyceum

是一套多人修改自 的軟體,以提供多人使用。WordPress and Lyceum 這篇提到關於 對於資料庫的設計:

From my examination of the code, it seems it’s exactly what is except they’ve modified every SQL statement (what a pain!) to use a monolithic table structure. We tested this approach for MU, but found it was too expensive to scale past a certain point. With monolithic structures you hit a wall based on your hardware.

In MU users are divided and can be partitioned easily, for example on we have the users partitioned between 4096 databases, which allows you to scale very cheaply and efficiently to hundreds of thousands and even millions of users and extremely high levels of traffic.

結果 對於 Database 的作法都一樣... (默)

MySQL 4.x/5.0 安全問題

MySQL 4.x/5.0 User-Defined Function Local Privilege Escalation Exploit,還看到 cvs tag...:

/*
 * $Id: raptor_udf2.c,v 1.1 2006/01/18 17:58:54 raptor Exp $
 *
 * raptor_udf2.c - dynamic library for do_system() MySQL UDF
 * Copyright (c) 2006 Marco Ivaldi <raptor@0xdeadbeef.info>
 *
 * This is an helper dynamic library for local privilege escalation through
 * MySQL run with root privileges (very bad idea!), slightly modified to work 
 * with newer versions of the open-source database. Tested on MySQL 4.1.14.

Oracle 與 Sleepycat 的消息

Greg Linden 的 Blog 上看到 想要買下 (也就是目前搞 Berkeley DB 的公司) 的新聞:Oracle to buy Sleepycat?。原新聞在 Oracle's Open-Source Shopping Spree

如果成真, 又有一個 Backend 被買走... (上次是 目前唯一支援 Row-Locking 的 Backend)

Update 【已經】被 買下了,參考:Oracle buys Sleepycat Software

FreeBSD 6.0 MySQL Performance

I use databases/mysql50-{client,server} and use benchmarks/super-smack to test. There are 3*2*2*2 = 24 cases:

  • Compile options: none, WITH_PROC_SCOPE_PTH=yes, WITH_LINUXTHREADS=yes
  • /etc/libmap.conf: none (libpthread), libthr
  • kern.timecounter.choice: ACPI-fast, TSC
  • kernel: ULE+PREEMPTION, ULE

These benchmarking were tested on my laptop (IBM x31 2672-IQV, Pentium-M 1.5G with 512MB RAM), and powerd was disabled. Detail informations (dmesg, sysctl, and kernel config file) will post later.

The commands are:

for i in 1 2 3 4 5; do super-smack select-key.smack 10 1000 | grep select_index; done
for i in 1 2 3 4 5; do super-smack update-select.smack 10 1000 | grep select_index; done

mysql-linuxthreads-libpthread-acpifast-ule+pre.txt

select_index    20000   0       0       14097.47
select_index    20000   0       0       13741.43
select_index    20000   1       0       13704.01
select_index    20000   0       0       13626.05
select_index    20000   0       0       13769.32
select_index    10000   2       0       1891.63
select_index    10000   2       0       1758.65
select_index    10000   2       0       1836.00
select_index    10000   4       0       2058.71
select_index    10000   14      0       2050.05

Continue reading

FreeBSD 6.0 MySQL Performance Tuning

這是 目前的討論:new benchmarks. WAS: FreeBSD MySQL still WAY slower than Linux

測試的環境是在本機上跑,主要的測試對象是 Thread Library,包括了:

  • libpthread (Default)
  • libpthread + LIBPTHREAD_PROCESS_SCOPE=yes
  • libthr
  • linuxthreads
  • linuxthreads (query cache disable)
  • libthr (query cache disable)
  • libthr (TCP socket)
  • linuxthreads (TCP socket)

這幾個測試結果沒有什麼意外,速度最快的是 libthr (即 1:1 Threading)。

另外因為上面的測試環境是打開 HTT 的情況下測出來的,所以有人建議關掉 HTT,而作者也再跑了一次,發現除了 libthr 快了一點點 (大約 2%) 以外,其他的都沒差。

再來是有人提出 上的 gettimeofday() 非常花資源 (這點在 提供的 mysql ktrace log 裡面有說到),所以有人有建議修改 kern.timecounter.hardware (從 ACPI-fast 改成 TSC),不過作者好像還沒看到 :p

再來是 kernel config file 裡面好像沒有用 SCHED_ULE

這個討論串還在跑,所以還可以看一看長輩們到底有什麼花樣可以玩...

Update:開新的討論串在討論了:mysql benchmarks。另外 super-smack 這個程式是 Sasha Pachev 發展的,後來 接手 (),現在是 在維護 ()。