Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to InnoDB #680

Open
Zankaria opened this issue Feb 22, 2024 · 5 comments
Open

Migrate to InnoDB #680

Zankaria opened this issue Feb 22, 2024 · 5 comments

Comments

@Zankaria
Copy link

Vichan still defaults to the ancient MyISAM storage engine which:

  • Has no transaction support.
  • Has mediocre concurrency support.

The former can be useful to improve the DB structure and data resiliency with foreign key constraints, which can be used to prevent dangling references to messages and posts in the nttpchan table, for example.
The latter I belive to be more of a pressing issue, as it can be very nasty for Vichan's performance. When MyISAM needs to insert a new post in any board table, it locks the whole table, which can easily result in long stalls if any other Vichan PHP processes tries to access it.
InnoDB has no such weakness, as it doesn't lock at table level but at row level, allowing for much higher concurrency.
Higher concurrency could also allow to merge all the board tables into a single table, where each post is identified by an automatically incremented numeric id, allowing to establish a total ordering of all the posts on the instance without having to rely on unix timestamps, which can easily go out of sync and result in data loss (something that has already happened at least once).

@RealAngeleno
Copy link

RealAngeleno commented Feb 23, 2024

That was something I did in the soyjak.party version of vichan yet never did in vichan itself, because of the differences in code from each place.

@Zankaria
Copy link
Author

That was something I did in the soyjak.party version of vichan yet never did in vichan itself, because of the differences in code from each place.

Well, this posits the question then: what are those differences? What needs to be changed?

@RealAngeleno
Copy link

probably not much

@Zankaria
Copy link
Author

The code you pushed doesn't provide an upgrade path though.
Namely, it doesn't convert existing tables

@RealAngeleno RealAngeleno reopened this Feb 23, 2024
@RealAngeleno
Copy link

big oversight. As I just went ALTER TABLE for everything manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants