- このトピックには15件の返信、1人の参加者があり、最後に
により3ヶ月、 1週前に更新されました。
-
投稿
-
お世話になっています。
バルニです現在MySQLで運用しています。ただMySQLが集計関数などが弱くてPostgeSQLにしたいなぁと思っています。
ただ回線が貧弱で前回1から構築した時に1週間ぐらいかかっているので、データはMySQLのものをそのままPostgreSQLにもっていきたいなと思っています。
これって可能でしょうか？やり方自体はCSVに吐き出してインポートするか、適当に吸い出すスクリプト書いて対応しようかなと思っています。テーブル構造が同じなら1〜2日で行けそうな気がするのですがテーブル構造は同じでしょうか？
テーブル構造が同じ場合に、テーブルだけ作成させるってできるでしょうか？すみません、これAPI keyが２つあるの今知りました。
PostgreSQLように一から作ろうと思います。バニルさん
既に解決されているかもしれませんが・・
PostgreSQLに移行するのは，mykeibadbを使って1からテーブルを構築することを推奨します．
これが一番確実かと．
以前のバージョンでは，データベース構築に律速だったのはインサートする過程だったので，アルゴリズムを改良したVer.4.0以降でかなり高速になっていると思います．次に，「テーブルのみを作る」については，wmykeibabのチェックを全て外した状態で実行すると，コードテーブル以外は空のテーブルが作成できると思います．
MySQL→PostgreSQLへのデータ移行はpgloaderなどの方法があるようですが，実際試してはいないのでうまくいくかは分かりませんね・・
ただデータ構造はMySQLとPostgreSQLで全く一緒にしているので，うまくいく可能性は高いと思います．よろしくお願いします．
Keough
お世話になっています。
ご回答ありがとうございます。現在4.1bでPostgreSQLではじめから構築しているのですが、MySQL版と数が合わなくて困っています。
※ログを出すようにしていただいたのですね。ありがとうございます。
※ターミナルの文字化けはフォントを色々入れたら直りましたが、ログ流れてしまうのでログファイルがあったほうが助かります。プログラムじたいは以下のログが出ているため正常に終了しているようです
RCVN:更新終了
－－－速報系データ－－－
0B15:更新データ無し
0B12:更新データ無し
0B30:更新データ無し
0B20:更新データ無し
0B11:更新データ無し
0B14:更新データ無し
0B13:更新データ無し
0B17:更新データ無し
0B51:スキップ
－－－時系列データ－－－
0B41:スキップ
0B42:スキップ
－－－勝負服変換－－－
勝負服:スキップ
－－終了時刻: 2026/3/31 21:27:46－－何回かfromtimeを000..や201800…にしたのですがなぜかmykeibadb.exeを実行すると2025年からのjvdファイルを取りに行っているようです。
RACE:O1SW2025050320250505132706.jvd || 134/1389=9.6% <==これって2025年のデータですよね？使用したクエリは以下です。
なぜ2025かというと2026は数が合わないのが少数。2024年以前はなぜかPostgreSQL版にデータが殆ど入らずでした。
3回fromtimeを000…にしてやってみたのですが2024年以前は殆どデータが入らずでした。select count(*) from umagoto_race_joho where kaisai_nen = ‘2025’
select count(*) from race_shosai where kaisai_nen = ‘2025’
上のクエリで以下の数字となります
postgres/mysql
umagoto_race_joho
55275/66655
race_shosai
4945/52762026年のデータ
umagoto_race_joho
13922/13927
race_shosai
1006/10062026はumagoto_race_johoはdata_kubun = ‘7’で検索すると12240で数があいました。
2025は全然合わずです。37358/47884でした。
古くなれば古くなるほどデータは少ないという特徴があります。あ
PostgreSQLのほうが必ず数が少ないのも有ります。umagoto_race_johoでみるとPostgreSQL版には以下のデータしか入りませんでした。
2025 55275
2024 11413
2023 4273
2022 1879環境はUbuntu24.04/wine 11.0ですが、MySQLでは動いているのでたぶんwineのせいじゃないと思っています。
以下にはデータがきちんと有ります。
.wine/drive_c/ProgramData/JRA-VAN/Data Lab/data`
-rw-rw-r– 1 1000 1000 509769 3月 31 01:56 SEVM2024079920240802135058.jvd
-rw-rw-r– 1 1000 1000 546609 3月 31 01:56 SEVM2024089920240902150210.jvd
-rw-rw-r– 1 1000 1000 414089 3月 31 01:56 SEVM2024099920240930143013.jvd
-rw-rw-r– 1 1000 1000 546708 3月 31 01:56 SEVM2024109920241101135413.jvd
-rw-rw-r– 1 1000 1000 718887 3月 31 01:56 SEVM2024119920241202150559.jvd
-rw-rw-r– 1 1000 1000 762166 3月 31 01:56 SEVM2024129920241229143624.jvd
-rw-rw-r– 1 1000 1000 526504 3月 31 01:56 SEVM2025019920250131140828.jvd
-rw-rw-r– 1 1000 1000 661130 3月 31 01:56 SEVM2025029920250228135015.jvd
-rw-rw-r– 1 1000 1000 514564 3月 31 01:56 SEVM2025039920250331142653.jvd
-rw-rw-r– 1 1000 1000 664774 3月 31 01:56 SEVM2025049920250502152842.jvd
-rw-rw-r– 1 1000 1000 637836 3月 31 01:56 SEVM2025059920250602144122.jvd
-rw-rw-r– 1 1000 1000 634797 3月 31 01:56 SEVM2025069920250630142123.jvd
-rw-rw-r– 1 1000 1000 588445 3月 31 01:56 SEVM2025079920250801141311.jvd
-rw-rw-r– 1 1000 1000 633971 3月 31 01:56 SEVM2025089920250901143526.jvd
-rw-rw-r– 1 1000 1000 509718 3月 31 01:56 SEVM2025099920251003140420.jvd
-rw-rw-r– 1 1000 1000 505150 3月 31 01:56 SEVM2025109920251031162626.jvd
-rw-rw-r– 1 1000 1000 636678 3月 31 01:56 SEVM2025119920251201145135.jvd
-rw-rw-r– 1 1000 1000 662421 3月 31 01:56 SEVM2025129920251229143354.jvd
-rw-rw-r– 1 1000 1000 603337 3月 31 01:56 SEVM2026019920260202142812.jvd
-rw-rw-r– 1 1000 1000 692790 3月 31 01:56 SEVM2026029920260302153033.jvddataを消したらJV-Linkは再取得するのかな？とおもって消してみたりもしたのですが状況変わらず。。
今はwineの再インストールからやり直していますが、やはり2025年からのデータを取りに行ってるようです。
お忙しいところ申し訳ありませんができたらPostgreSQLを使いたいので調査していただけないでしょうか？
こちらから出せるログは出させていただきます。
Windowsで試すというのでしたらkvm上にWindowsいますのでWindowsでも試せます。以上、よろしくおねがいします。
とりあえずWindows上で実行したらRACEが1986からのjvdファイルを処理しだしました。
wine環境のせいのようです。
なんでだろ？バニルさん
MySQLでは1986年のデータから問題なく読み込みできますでしょうか。
アルゴリズムは、JVLinkでReadする部分も含めてほぼ一緒なので、もし症状出るのであればMySQLでも同じように起こるはずなのですが。。当方でもWine環境試してみようと思いますが、少々時間かかると思います。
Keough
そういえばMySQLは当初Windowsで取り込んであとからWine環境にした気がします。
あとで試してみます。
すみません、お手数おかけしてしまって。
wineをもし試していただけるのでしたらハマりポイントをいくつか上げておきます。
wineは最新のものを試したほうが良いと思います。最初winecfgで$HOME/.wineを作成します
wineの構築中にmonoを聞かれますがたぶんインストールしないほうが良いです。あとから.net48をインストールしたほうが良さげです。
文字化け対策
winetricksでinstall applicationを選んでcancelするとinstall fontがあるのですがここで
cjkfontsとfakejapaneaseとfakejapananease_ipamona fakejapanese_vlgothicとipamonaを選択してインストールしてください。これで多分文字化けはなくなります。.net48とvb6のインストール
winetricksでInstall a Windows DLL or componentを選択しdotnet48とvb6を選んでください。JV-Linkをwineでインストールwine JV-Link.exeした後に$HOME/.wine/drive_c/Program Files (x86)/JRA-VAN/Data Lab以下のJV-Link設定.exeをwineで実行してももしかしたら、状態を取得するをおしても303エラーとかかるかもしれません。一度利用キーを入力してokしてから再度試すか、もしくはMSFLXGRD.OCXが登録されてない可能性もあるのでwine regsrv32で登録してみてください。
たぶんハマりポイントはこれだけだと思います。
wineの情報はググっても古くてあまり当てにならないのですが、結構使えるなって思っています。
あとwine実行時にワーニングがばーって出ますがこれは気にしないで良さそうです。JV-Linkが.NETになってくれたらLinuxにも.NETあるのでもっと簡単に動きそうなんだけどなって思っています。
お疲れ様です
MySQLの方はなぜか1986年のデータから処理しています。
昨日PostgreSQLを試していたときは2025年のjvdファイルから処理しだしていたので状況はかなり違います。お手数おかけしてしまってすみません。
Keoughさん
ありがとうございます。
お手数おかけしてしまってすみません。僕もWindowsからUbuntu上のPostgreSQLへは1986年から開始されており問題ございません。
一旦環境を整えたいのでこのままデータを作ろうと思います。
一昨日おかしかったのはWine上でして、MySQLへ今同じマシン(Wine)から流し込んでいるのですがこちらは問題なく1986年から始まっています。
環境整ったら(今のPostgreSQLのDBが完成したら)またWine上からUbuntu上のPostgreSQLへやってみようと思います。#たぶん来週中の何処かで今回データを作り直したりしていて1点気になった点があります。
MySQLについて
たぶんlower_case_table_names=1このオプションつけて作ったDBじゃないとMySQLがLinux上だとエラーで止まるかなと思います。
README.txtに付け加えたほうがいいかと思います。
Linux上だとこれつけないとtable名が大文字小文字区別されてしまいますので。バニルさん
コメントありがとうございます．
根本原因が究明できるまではなんとか凌いでいただきたく，済みませんがよろしくお願いします．Linux上MySQLでの大文字/小文字の識別ですが，認識しており，mykeibadbを使ってLinux上に作ったテーブル(大文字になります)をそのまま使う分には問題ないと思っています．
ただ例えばWindows上MySQLで作ったテーブル(小文字)を，Linuxにそのまま移行するような場合は，エラーにはなりませんが，大文字と小文字のテーブルがダブルで作られ別テーブルとして認識されてしまうので，次回Update時にはその旨Readme.txtに記載することにします．Keough
バニルさん
まだWine+PostgreSQLの環境を試せていませんが，ひょっとすると影響しているかもしれない箇所を修正してみました．
以下に置いていますので確認いただけますでしょうか．よろしくお願いします．
Keough
keoughさん
ありがとうごじます。
気が付きませんで返信遅れました。試してみます。
とりあえずご返信まで。keoughさん
早速試してみたところ処理は1986から始まりました。
これで流し込んでみてもう一つの方のDB(Windowsから作った方のDB)と差異がないか調べてみようと思います。
流し終わったらまたご連絡します。
迅速な対応ありがとうございました。
感謝します。
