evazion f49b3c439f posts: optimize modqueue page, status:modqueue, and status:unmoderated searches.
* Optimize status:modqueue and status:unmoderated searches. This brings them down from
  taking 500ms-1000ms per search to ~5ms.

* Change status:unmoderated so that it only filters out the user's disapproved posts, not
  the user's own uploads or past approvals. Now it's equivalent to `status:modqueue -disapproved:evazion`,
  whereas before it was equivalent to `status:modqueue -disapproved:evazion -approver:evazion -user:evazion`.
  Filtering out the user's own uploads and approvals was slow and usually unnecessary,
  since for most users it's rare for their own uploads or approvals to reenter the modqueue.

Before status:modqueue did this:

   SELECT * FROM posts WHERE is_pending = TRUE OR is_flagged = TRUE OR (is_deleted = TRUE AND id IN (SELECT post_id FROM post_appeals WHERE status = 0))

Now we do this:

   SELECT * FROM posts WHERE id IN (SELECT id FROM posts WHERE is_pending = TRUE UNION ALL SELECT id FROM posts WHERE is_flagged = TRUE UNION ALL SELECT id FROM posts WHERE id IN (SELECT post_id FROM post_appeals WHERE status = 0))

Postgres had a bad time with the "pending or flagged or has a pending appeal" clause because
it didn't know that posts can only be in one state at a time, so it overestimated how many
posts would be returned and chose a seq scan. Replacing the OR with a UNION avoids this.
2022-09-28 00:29:50 -05:00
2019-10-28 21:37:34 -05:00
2022-04-27 03:47:59 +02:00
2021-03-01 00:39:47 -06:00
2022-04-23 21:16:37 -05:00
2017-10-09 14:45:23 -07:00
2022-05-22 02:53:22 -05:00
2022-03-15 14:06:16 +01:00
2022-04-09 14:54:15 +02:00
2021-09-14 21:40:39 -05:00
2022-04-21 21:43:06 -05:00
2020-06-27 13:03:04 -05:00
2021-06-17 04:10:26 -05:00
2022-01-17 11:58:19 -06:00
2021-03-01 00:39:47 -06:00
2021-03-31 21:32:01 -05:00
2021-09-20 06:17:57 -05:00
2020-06-07 17:14:41 -05:00
2022-06-28 03:12:46 -05:00
2022-04-21 21:43:06 -05:00
2021-01-28 16:20:56 +09:00
2022-03-06 23:28:53 -06:00
2019-12-22 21:23:37 -06:00
2021-09-24 08:40:33 -05:00
2022-09-07 03:13:13 -05:00

codecov Discord

Quickstart

Run this to start a basic Danbooru instance:

curl -sSL https://raw.githubusercontent.com/danbooru/danbooru/master/bin/danbooru | sh

This will install Docker Compose and use it to start Danbooru. When it's done, Danbooru will be running at http://localhost:3000.

Alternatively, if you already have Docker Compose installed, you can just do:

wget https://raw.githubusercontent.com/danbooru/danbooru/master/docker-compose.yaml
docker-compose up

Manual Installation

Follow the INSTALL.debian script to install Danbooru.

The INSTALL.debian script is written for Debian, but can be adapted for other distributions. Danbooru has been successfully installed on Debian, Ubuntu, Fedora, Arch, and OS X. It is recommended that you use an Ubuntu-based system since Ubuntu is what is used in development and production.

See here for a guide on how set up Danbooru inside a virtual machine.

For best performance, you will need at least 256MB of RAM for PostgreSQL and Rails. The memory requirement will grow as your database gets bigger.

In production, Danbooru uses PostgreSQL 10.18, but any release later than this should work.

Troubleshooting

If your setup is not working, here are the steps I usually recommend to people:

  1. Test the database. Make sure you can connect to it using psql. Make sure the tables exist. If this fails, you need to work on correctly installing PostgreSQL, importing the initial schema, and running the migrations.

  2. Test the Rails database connection by using bin/rails console. Run Post.count to make sure Rails can connect to the database. If this fails, you need to make sure your Danbooru configuration files are correct.

  3. Test Nginx to make sure it's working correctly. You may need to debug your Nginx configuration file.

  4. Check all log files.

Services

Danboou depends on a couple of cloud services and several microservices to implement certain features.

Amazon Web Services

The following features require an Amazon AWS account:

  • Pool history
  • Post history

Google APIs

The following features require a Google Cloud account:

  • BigQuery database export

IQDB Service

IQDB integration is delegated to the IQDB service.

Archive Service

In order to access pool and post histories you will need to install and configure the Archives service.

Reportbooru Service

The following features are delegated to the Reportbooru service:

  • Post views
  • Missed searches report
  • Popular searches report

Recommender Service

Post recommendations require the Recommender service.

Description
No description provided
Readme 68 MiB
Languages
Ruby 78.3%
HTML 13.5%
JavaScript 3.5%
SCSS 2.5%
Nix 1.6%
Other 0.5%