5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

オープンソースDataBase

1 :名無しさん@お腹いっぱい。:03/05/01 04:52
PostgreSQL,MySQL,Firebird,その他
UNIX / BSD / Linux で使える
オープンソースなDataBaseに関する雑談・相談スレ

2 :名無しさん@お腹いっぱい。:03/05/01 04:53
参考リンク

MySQL:
  http://www.mysql.com/
  http://www.mysql.gr.jp/

PostgreSQL:
  http://www.postgresql.org/
  http://www.postgresql.jp/

Firebird:
  http://firebird.sourceforge.net/
  http://www.egroups.co.jp/group/Firebird-jp-general


3 :名無しさん@お腹いっぱい。:03/05/01 04:56
>>1
このスレは
PostgreSQL or MySQL
http://pc.2ch.net/test/read.cgi/unix/955533785/
の次スレで、他の db も視野に入れたという位置付けでいいのでしょうか?

4 :1:03/05/01 05:08
>>3
それでOKです
でも、そのスレは質問から自然発展したような流れでしたので
ちゃんとDBについて考察するスレがUNIX板にも1つは必要かと思い
立ててみました。(笑

5 :名無しさん@お腹いっぱい。:03/05/01 05:13
Open Sourceがカナでデータベースがローマ字ってのはかなり妙

6 :名無しさん@お腹いっぱい。:03/05/01 05:37
で、Firebirdってどーなの?誰か使ってますか?
Firebirdは結局のところInerBaseなんでしょ?
MozillaとNetscapeの関係と同じだと認識しているのだがどーなのさ。

7 :名無しさん@お腹いっぱい。:03/05/01 05:55
>>6 IB6はFreeBSDで動かないけどFirebirdだと動く

しかし,マジで使うならPostgresの方が安心感はある,
だからFirebirdは使ったことありません MySQLは時々使うけどね.

8 :名無しさん@お腹いっぱい。:03/05/01 06:01
>>5 しかし,DataBaseがローマ字って表現も妙
我々の仲間内ではアルファベットとか英字と表現します.

9 :名無しさん@お腹いっぱい。:03/05/01 06:11
ローマ字なら「だたばせ」って読むことになるのか?

10 :あぼーん:あぼーん
あぼーん

11 :名無しさん@お腹いっぱい。:03/05/01 12:29
ぶっちゃけ「Firebirdって遅い」んだよなぁー
どうやったら早くなるのか誰か教えてくれー
ちなみにおいらが検索スピードを調べた結果をさらすと
PostgreSQL > MySQL(MyISAM) > Firebird の順番だった
#データ件数1000万&仮想クライアント数400
クライアント1台からSQL叩くんならFirebirdって結構早いんだけどね
ついでにMySQLのInnoDBもクライアント数が増えると遅いよぉ

12 :名無しさん@お腹いっぱい。:03/05/01 16:16
>>11
インデックスキーの持ち方が独特なので、そのせいかも。

但し、これもデータ件数やインデックスの数が少ないISAM的なデータで
>>11が書いたみたいにクライアント台数が極端に少ない環境では
効率が良い場合もある、よくIBは小中規模程度のシステム向けと
言われることの理由の1つで管理ツールやDB管理が簡単である点等の
メリットを感じなければ業務用途ではPostgreSQLを使うのが最良だと思う。


13 :11:03/05/01 17:56
>>12
データ自体も圧縮して持ってるとかどこかに書いてあったし
インデックスも色々やってるみたいですね.

チューニングしようにもパラメタがロクにないんで正直手詰まり状態です.
CS・SSとも色々やってみたんですが性能は大きく変わったりしませんでした.
Ver1.5で早くなっているとか某MLで出てましたけど,そっちに期待かな...

14 :名無しさん@お腹いっぱい。:03/05/01 20:21
>>13
postgresもデータ圧縮してなかったっけ?
Firebirdって、データファイルを一つにまとめちゃうんでしょ?
それの弊害って有りそう。

15 :11:03/05/02 10:45
>>14
Firebirdはデータファイルを複数にもできるんですよ.このへん微妙ですね.
MySQLのInnoDBみたいな感じで設定します.分散された中身をどう使っている
のかは,各RDBMSそれぞれの実装依存なのだと思います.
#ソースをハックしてるワケではないので詳細は知らないんです.

PostgreSQLって圧縮してましたっけ?今は分からないっす.

16 :11:03/05/02 17:10
圧縮を調べようと思っているんだけど,PostgreSQLのデータってどこにあんの?
とりあえず/var/lib/pgsql/dataをdu -hしたら8.5GBでした.
同じデータをMySQL(MyISAM)だと2.9GB.Firebirdだと3.6GB.ですた.
#EXT3での値です.
MyやFBに比べて圧縮率は低めのようですね.

ついでにWindows版(NTFS)も晒しておきますと
Oracle8.1.6=12.8GB
SQLServer2000=4.2GB
Firebird=3.9GB
MySQL(MyISAM)=2.4GB
MySQL(InnoDB)=11.2GB
いちおう参考までにということで.

17 :名無しさん@Emacs:03/05/03 04:20
>PostgreSQLって圧縮してましたっけ?今は分からないっす.

可変長属性で実際のデータが8k越えるものは圧縮されます。
「PostgreSQL TOAST」で検索しる。


18 :11:03/05/06 08:28
>「PostgreSQL TOAST」で検索しる。
やだ

19 :名無しさん@お腹いっぱい。:03/05/06 21:23
>>18
なんで?

20 :18:03/05/07 08:36
実装までは興味ないからだよ.

要約してここに書いてくれれば読むけど
自ら調べる程の価値は感じない情報って感じ

21 :名無しさん@お腹いっぱい。:03/05/08 01:06
>>20
あっそ

22 ::03/05/11 11:40
postgreSQL 7.0.3で、
1.DBダンプをはいてハックアップ
2.データベースDROP
3.データベースCREATE
4.DBダンプをロード
という運用をしているのですが、
この場合だと「VACUUM」を
使用する必要はないのでしょうか?

#この運用でpostgresが死んだので・・・
#他に原因が考えられない(^_^;)

23 :名無しさん@お腹いっぱい。:03/05/11 11:54
>>22
死んだってどういうこと?

確かにこれなら vacuum 必要ないけど、いちいちこんな事やるの
すげー面倒じゃないか?

24 :名無しさん@お腹いっぱい。:03/05/11 13:22
>>22
必要か不必要かっていえば別に必要じゃないけど、
まともに使いたいなら vacuum --analyze はやっておくべし。
トラブルの原因は知らんけど。

25 :名無しさん@お腹いっぱい。:03/05/11 13:46
おまえら、SQL Serverスレで
ぽすぐれは高負荷時にバックアップ取ると死ぬ
と主張されてる香具師がおりまつが誠でつか?

つか、どのくらいの負荷だと死にますかね?
いくらなんでも、ヘタレな漏れの 6.3〜6.8 くらいの負荷では
いつバックアップやっても無問題ですよね?

26 :名無しさん@お腹いっぱい。:03/05/12 01:59
>>23
全然面倒じゃないです。
シェルスクリプトにして、
cronで毎日自動実行。

#やはり、vacuumは必要ではない、と・・。

#DROP&CREATEで不要領域はクリアされるのか・・・。

27 :名無しさん@お腹いっぱい。:03/05/12 11:22
>>26
index はどうするの? analyze しないと index を使ってくれないはず。

28 :名無しさん@Emacs:03/05/12 15:11
>26
drop tableすればテーブルのファイルそのものが削除されるんだから、
その後のcreate tableのときに不要領域が無くなるのは当然。

それより、>27も言ってるように、analyzeしないと統計情報が
更新されないから、オプティマイザがアホなままですよ。

つか、何のために>22みたいなことを毎日やってんの?


29 :名無しさん@お腹いっぱい。:03/05/12 16:31
予想。

システムが構築された時期は2年位前。
アクセス数はごく少数のシステムで、
夜中は一応サービス時間帯にはなっているが、アクセス数はほぼゼロ。

いままで問題なかったけど、vacuum 実行してなかったので
ディスクが一杯になってしまった、または性能が劣化した。

どうせ vacuum しなければならないんだったら、
drop して再構築すればいいと考えた。
担当者の技術レベルはそんなに高くない。というか素人レベル。

検証の手間をかけれられないので、
concurrent vacuum をサポートした新しいバージョンは使えない。
もしくは、複数のバージョンの postgres を共存させる手法を知らないだけ。

こんなところか?

30 :名無しさん@Emacs:03/05/12 22:41
自分のやってることを理解してないエンジニアつのはどうなのかね。


31 :名無しさん@お腹いっぱい。:03/05/13 01:45
>>システムが構築された時期は2年位前。
惜しい。1年くらい前。


>>アクセス数はごく少数のシステムで、
アクセス数は「ごく少数」でもないが、それほど多くもない。
ホームページなんだけどね。イントラネットの。

>>夜中は一応サービス時間帯にはなっているが、アクセス数はほぼゼロ。
いえ、夜中はサービスしてません。アクセス数ほぼゼロは当たり。

>>いままで問題なかったけど、vacuum 実行してなかったので
>>ディスクが一杯になってしまった、または性能が劣化した。
よくわかりません。ディスクは一杯じゃないけど・・・。

>>どうせ vacuum しなければならないんだったら、
>>drop して再構築すればいいと考えた。
>>担当者の技術レベルはそんなに高くない。というか素人レベル。
「素人レベル」・・・。当たり。というより、素人そのもの。
その辺のおっさんレベルです。
訳のわからんまま引き継いだが、
他の仕事がいそがしくて、みてる暇がないまま、トラブル発生。

>>検証の手間をかけれられないので、
当たり。
>>concurrent vacuum をサポートした新しいバージョンは使えない。
>>もしくは、複数のバージョンの postgres を共存させる手法を知らないだけ。
知りません。

>>こんなところか?
結構あってますね。

32 :名無しさん@お腹いっぱい。:03/05/13 13:02
自分のやってることを理解してないエンジニアつのはどうなのかね。

>>自分のやってることを恥ずかしく思わないエンジニアつのはどうなのかね。


33 :名無しさん@お腹いっぱい。:03/05/13 13:06
ところで、24はなぜPostgreSQLがそういう運用だと死ぬのか分かったんかい?



34 :あぼーん:あぼーん
あぼーん

35 :名無しさん@お腹いっぱい。:03/05/14 00:30
SQLITE
ttp://www.hwaci.com/sw/sqlite/


36 :名無しさん@お腹いっぱい。:03/05/16 02:33
PostgreSQLで質問です。

pg_dumpを実行してテーブルの構造やPL/pgSQLの関数を吐き出してみたのですが、
出力順がバラバラで読みにくくて仕方ありません、
名称順にソートしたり出来ないのでしょうか?
または、pg_dump以外にPL/pgSQLの定義や関数を取り出す方法があれば
教えて下さい。

37 :名無しさん@Emacs:03/05/16 11:00
PL/pgSQLでindexが効かないのですが?
知っている人いませんか?

38 :名無しさん@お腹いっぱい。:03/05/16 14:50
>>37か神のみぞ知る

39 :名無しさん@お腹いっぱい。:03/05/16 21:28
FreeBSDにPostgreSQLがインストールできないんですが?
何か知っている人いませんか?

40 :名無しさん:03/05/17 07:15
>39
何がどうできないのか、状況きちんと書け。


41 :名無しさん@お腹いっぱい。:03/05/17 10:08
おまえらPostgreSQLをgccでコンパイルするときに -march を指定していますか?
俺んとこだと -march=pentium3 以上にすると initdbでsignal 4を喰らいます。
FreeBSDだと-STABLEでも-CURRENTでも出ました。gccは2.9xと3.2の両方試しました。
他のOSではどうすか?

42 :あぼーん:あぼーん
あぼーん

43 :名無しさん@お腹いっぱい。:03/05/17 10:50
Date: 16 May 2003 14:15:00 +0900
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: [HACKERS] Heads up: 7.3.3 this Wednesday

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),
God willin' an' the creek don't rise. If anyone's got anything you've
been planning to fix in the 7.3 branch, now is a real good time to get
it done.

44 :名無しさん@お腹いっぱい。:03/05/20 02:41
データベースとデータベース管理システムを区別してくだちい

45 :名無しさん@お腹いっぱい。:03/05/20 18:30
PostgreSQL 7.3.2 付属ドキュメント
http://www.postgresql.jp/document/pg732doc/

46 :名無しさん@お腹いっぱい。:03/05/21 01:19
rootやら普段の作業用のアカウントやら
PostgreSQLやMySQLのスーパーユーザーやらが
各マシンに点在しててもはや脳味噌がパンク
しそうです。PostgreSQLなんかにパスワード
を全部メモしておくのはやっぱ危険かな?

47 :名無しさん@お腹いっぱい。:03/05/21 09:33
>>46
メモに書いとくほうが1万倍マシ。

48 :名無しさん@お腹いっぱい。:03/05/21 18:55
やっぱそうだよね。。そうします。

49 :名無しさん@お腹いっぱい。:03/05/21 19:31
パスワードに関しては
紙にメモ >>>>>> PDA >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DB
だろうな。どんなに多くたって100個程度なんだから、検索性なんて
無視して OK なんだし。

紙だと人から見られたときどうするのという問題があるんで、PDA でパスワードの
書いてある表をパスワードロックしておくというのもありだけど、この辺は
セキュリティに関しての考えかた次第かな。

50 :あぼーん:あぼーん
あぼーん

51 :a:03/05/22 02:46
e

52 :名無しさん@お腹いっぱい。:03/05/22 09:33
Date: 21 May 2003 02:04:00 +0900
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: [HACKERS] Heads up: 7.3.3 this, er, Friday
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>

Well, the postgresql.org server move has proven to be much messier than
we hoped, so it seems prudent to delay a couple days while the kinks
get worked out. New plan is 7.3.3 release on Friday (5/23).

53 :名無しさん@お腹いっぱい。:03/05/22 09:47
難しい英語でつね

54 :名無しさん@お腹いっぱい。:03/05/22 12:14
超訳

v 7.3.3.はほんとは21日にリリース予定だったけど、
ちょっと遅れて23日金曜日にリリースするよ、ゴメンよ。


55 :名無しさん@お腹いっぱい。:03/05/23 21:50
列にUNIQUEを指定するとその列の値が重複する行をINSERTするときにエラーがでますが、
エラーを出さずにあたかもINSERTが成功したかのように結果を返す(しかし実際には重複行
はINSERTしない)ようにするにはどうしたらいいですか?

56 :名無しさん@お腹いっぱい。:03/05/23 22:47
そんなことをしたい糸が分からん。

57 :名無しさん@お腹いっぱい。:03/05/23 23:35
弊害の方が多いような気が。
クライアント側のエラー表示を消したいということなら、
自分でエラーハンドリング(この場合は非表示か?)した方がよいのでは?

58 :名無しさん@お腹いっぱい。:03/05/24 04:53
INSERT しようとするSQL側にINSERT先のキーになってる項目を参照して
アンマッチなデータだけINSERTするようにしたら?

一番簡単にやるならトランザクションにして、
INSERT先の該当データをバサっと消してから全てをINSERTしたら?

68 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)